Если вы откроете VMware vSphere Client и посмотрите на список виртуальных дисков, прикрепленных к виртуальному модулю (Virtual Appliance) сервера vCenter, то вы увидите там аж 17 виртуальных дисков VMDK. Многие администраторы удивляются - а не многовато ли это?

Для VMware vSphere 7 список дисков и их назначение указаны в статье базы знаний KB 78515 (их там 16), ну а ниже мы расскажем о семнадцати VMDK для VMware vSphere 8:

Много? Много!

Пару дней назад мы писали о новом пользовательском интерфейсе лабораторных работ Hands-On Labs, который появился на HoL портале VMware. Сегодня мы расскажем о том, какие лабы стали доступны для пользователей в этом году, а также о тех лабах, которые были заменены на их более актуальные версии.

Итак, что нового на Hands-On Labs:

Ну а вот какие лабы устарели и были заменены их более свежими версиями:

Напомним, что актуальный список лабораторных работ VMware Hands-On Labs вы можете найти по этой ссылке.

На конференции VMworld 2020 Online ковидного года компания VMware представила одну из самых интересных своих инициатив по сотрудничеству с вендорами оборудования - Project Monterey. Тогда была представлена технология SmartNIC/DPU, которая позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.

SmartNIC - это специальный сетевой адаптер (NIC) c модулем CPU на борту, который берет на себя offload основных функций управляющих сервисов (а именно, работу с хранилищами и сетями, а также управление самим хостом).

В данном решении есть три основных момента:

• Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличивает пропускную способность и уменьшает задержки (latency).
• Унифицированные операции для всех приложений, включая bare-metal операционные системы.
• Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности. Ведь если основной ESXi для исполнения рабочих нагрузок будет скомпрометирован, то управляющий DPU сможет обнаружить ее и устранить уязвимость.

В статье об аппаратных нововведениях платформы VMware vSphere 8 Update 2, представленных на конференции Explore 2023, мы писали о том, что VMware еще в vSphere 8 представила поддержку DPU, позволяя клиентам переносить инфраструктурные рабочие нагрузки с CPU на специализированный модуль DPU, тем самым повышая производительность бизнес-нагрузок. Ну а в vSphere 8 U2 клиенты, использующие серверы Lenovo или Fujitsu, теперь смогут использовать новые функции интеграции vSphere DPU и его преимущества в производительности.

Теперь в платформах vSphere 8 и NSX есть полноценная поддержка устройств SmartNIC или так называемых устройств обработки данных (DPU). Реализация DPU в vSphere называется vSphere Distributed Service Engine.

DPU (SmartNIC) — это сетевые карты с встроенным интеллектом, которые могут выполнять различные сетевые функции непосредственно на адаптере через свои собственные программируемые процессоры. В дополнение к сетевым ускорителям, такие DPU, как NVIDIA BlueField, также имеют ядра общего назначения на базе процессора Arm, которые могут запускать полноценную систему ESXi (вот для чего и пригодился гипервизор VMware ESXi Arm Edition).

С технологией DPU, службы NSX, такие как маршрутизация, коммутация, брандмауэр и мониторинг, снимаются с хост-гипервизора и переносятся на DPU. С помощью этих возможностей возможно улучшить производительность, освободить ресурсы на хосте и изолировать рабочую нагрузку и инфраструктурные домены.

Об этом всем и рассказывается в документе "Optimizing Networking and Security Performance Using VMware vSphere and NVIDIA BlueField DPU with BWI", который очень полезно прочитать для общего развития:

Ну и несколько картинок по результатам тестирования хостов ESXi с модулями SmartNIC/DPU на борту, которые показывают, какой прирост производительности дает новая технология:

Продолжаем рассказывать об интересных анонсах главного события года в мире виртуализации - конференции VMware Explore 2023. Сегодня организации стремятся использовать AI, но беспокоятся о рисках для интеллектуальной собственности, утечке данных и контроле доступа к моделям искусственного интеллекта. Эти проблемы определяют необходимость корпоративного приватного AI.

Об этом недавно компания VMware записала интересное видео:

Рассмотрим этот важный анонс немного детальнее. Вот что приватный AI может предложить по сравнению с публичной инфраструктурой ChatGPT:

• Распределенность: вычислительная мощность и модели AI будут находиться рядом с данными. Это требует инфраструктуры, поддерживающей централизованное управление.
• Конфиденциальность данных: данные организации остаются в ее владении и не используются для тренировки других моделей без согласия компании.
• Контроль доступа: установлены механизмы доступа и аудита для соблюдения политик компании и регуляторных правил.

Приватный AI не обязательно требует частных облаков, главное — соблюдение требований конфиденциальности и контроля.

Подход VMware Private AI

VMware специализируется на управлении рабочими нагрузками различной природы и имеет огромный опыт, полезный для имплементации успешного приватного AI. К основным преимуществам подхода VMware Private AI относятся:

• Выбор: организации могут легко сменить коммерческие AI-сервисы или использовать открытые модели, адаптируясь к бизнес-требованиям.
• Конфиденциальность: современные методы защиты обеспечивают конфиденциальность данных на всех этапах их обработки.
• Производительность: показатели AI-задач равны или даже превышают аналоги на чистом железе, как показали отраслевые тесты.
• Управление: единый подход к управлению снижает затраты и риски ошибок.
• Time-to-value: AI-окружения можно быстро поднимать и выключать за считанные секунды, что повышает гибкость и скорость реакции на возникающие задачи.
• Эффективность: быстрое развертывание корпоративных AI-сред и оптимизация использования ресурсов снижают общие затраты на инфраструктуру и решение задач, которые связаны с AI.

Таким образом, платформа VMware Private AI предлагает гибкий и эффективный способ внедрения корпоративного приватного AI.

VMware Private AI Foundation в партнерстве с NVIDIA

VMware сотрудничает с NVIDIA для создания универсальной платформы VMware Private AI Foundation with NVIDIA. Эта платформа поможет предприятиям настраивать большие языковые модели, создавать более безопасные модели для внутреннего использования, предлагать генеративный AI как сервис и безопасно масштабировать задачи генерации результатов. Решение основано на средах VMware Cloud Foundation и NVIDIA AI Enterprise и будет предлагать следующие преимущества:

• Масштабирование уровня датацентров: множественные пути ввода-вывода для GPU позволяют масштабировать AI-загрузки на до 16 виртуальных GPU в одной виртуальной машине.
• Производительное хранение: архитектура VMware vSAN Express обеспечивает оптимизированное хранение на базе хранилищ NVMe и технологии GPUDirect storage over RDMA, а также поддерживает прямую передачу данных от хранилища к GPU без участия CPU.
• Образы виртуальных машин vSphere для Deep Learning: быстрое прототипирование с предустановленными фреймворками и библиотеками.

В решении будет использоваться NVIDIA NeMo, cloud-native фреймворк в составе NVIDIA AI Enterprise, который упрощает и ускоряет принятие генеративного ИИ.

Архитектура VMware для приватного AI

AI-лаборатории VMware совместно с партнерами разработали решение для AI-сервисов, обеспечивающее приватность данных, гибкость выбора ИИ-решений и интегрированную безопасность. Архитектура предлагает:

• Использование лучших моделей и инструментов, адаптированных к бизнес-потребностям.
• Быстрое внедрение благодаря документированной архитектуре и коду.
• Интеграцию с популярными открытыми проектами, такими как ray.io, Kubeflow, PyTorch, pgvector и моделями Hugging Face.

Архитектура поддерживает коммерческие и открытые MLOps-инструменты от партнеров VMware, такие как MLOps toolkit for Kubernetes, а также различные надстройки (например, Anyscale, cnvrg.io, Domino Data Lab, NVIDIA, One Convergence, Run:ai и Weights & Biases). В состав платформы уже включен самый популярный инструмент PyTorch для генеративного AI.

Сотрудничество с AnyScale расширяет применение Ray AI для онпремизных вариантов использования. Интеграция с Hugging Face обеспечивает простоту и скорость внедрения открытых моделей.

Решение Private AI уже применяется в собственных датацентрах VMware, показывая впечатляющие результаты по стоимости, масштабу и производительности разработчиков.

Чтобы начать использование VMware Private AI можно начать с прочтения референсной архитектуры и примеров кода. Также очень полезной вам может оказаться вот эта статья от VMware.

Многие клиенты VMware используют кластерные приложения, такие как Microsoft WSFS и Oracle RAC, на платформе vSphere. Эти кластерные системы требуют, чтобы диски были общими для всех серверных узлов внутри приложения. Одним из требований к механизму блокировки дисковых ресурсов является использование SCSI3-Persistent Reservations или режим multi-writer.

Пользователи VMware vSphere обычно применяли физический pRDM для кластерных приложений. С выпуском vSphere 6.7 SCSI3-PR были добавлены к vVols, и это вызвало большой интерес со стороны администраторов. RDM не так просты просты в эксплуатации, они требуют ручного выделения и назначения индивидуальных LUN для всех узлов кластера приложения. Это создает большую операционную нагрузку. Также в этом случае ограничены некоторые возможности виртуализации при использовании томов RDM и требуется взаимодействие с администратором хранилища для изменения его размера. Кроме того, вам также следует помечать свои RDM флагом "Perennially Reserved" для сокращения времени загрузки и повторного сканирования хранилищ.

Внедрению технологии vVols мешало отсутствие одной конкретной функции — возможности увеличивать размер общих дисков, когда кластерное приложение работает.

С выпуском VMware vSphere 8.0 Update 2 было устранено последнее преимущество RDM перед vVols. Теперь вы можете увеличивать размер общих дисков (физическое совместное использование шины physical bus sharing или же multi-writer) без необходимости останавливать кластер приложения. Для WSFC первоначально поддерживается SCSI, но для Oracle RAC поддерживаются и SCSI, и NVMeoF (FC, TCP).

Это означает, что клиентам больше не нужно выполнять все ручные операции по выделению RDM LUN для кластерных приложений. Они могут использовать vVols и выделять приложение и ВСЕ диски на стандартном хранилище данных vVols. Это позволяет клиентам значительно упростить развертывание кластерных приложений и снизить сложность их среды. Это также упрощает ежедневные операции администратора хранилища, поскольку администратор виртуальной инфраструктуры теперь может создавать и изменять размер общих дисков прямо из vCenter! Другим преимуществом является то, что vVols не являются традиционными LUN, и время повторного сканирования хранилищ и время загрузки хоста не зависят от количества выделенных vVols, в отличие от RDM, если только они не помечены флагом Perennially Reserved.

Чтобы показать вам, насколько проста операция изменения размера, VMware сделала короткое демо, показывающее процесс увеличения общего диска в активном кластере Microsoft WSFC (кликните на картинку для открытия GIF в новом окне):

В рамках прошедшей недавно конференции Explore 2023 компания VMware сделала немало интересных анонсов продуктов и технологий, которые появятся в ближайшем будущем. Одной из главных новостей стало объявление о скором выпуске второго пакета обновлений флагманской платформы виртуализации VMware vSphere 8 Update 2. Сегодня мы рассмотрим ту ее часть, которая касается аппаратного обеспечения, а особенно нагрузок, использующих модули GPU для задач искусственного интеллекта, графических приложений...

Не так давно мы писали о нововведениях VMware в средствах автоматизации виртуальной инфраструктуры VMware vSphere в 2023 году. Ключевой элемент в процессе использования средств автоматизации для платформы vSphere - это пакет разработки ПО Software Development Kit (SDK).

VMware vSphere предоставляет разнообразный выбор SDK для автоматизации рабочих процессов. Пользователи часто задаются вопросом выбора SDK для автоматизации конкретных задач. Вот некоторые рекомендации по использованию различных SDK для задач автоматизации.

Выбор SDK

Основные API vSphere разделены на три категории на основе используемого протокола. Библиотеки наборов инструментов для разработки программного обеспечения vSphere также классифицируются на основе них.

• vSphere Web Services (VIM) API - это популярные API, охватывающие большую часть инфраструктуры vSphere с использованием протокола SOAP. pyvmomi, govmomi и vSphere Management Java SDK широко используют эти API. Все устаревшие функции, предшествующие vSphere 6.5, доступны только в этих SDK.
• vSphere Automation API - API автоматизации vSphere следует архитектуре REST на основе ресурсов, которая была введена в vSphere 6.5. VMware vSphere Automation SDK оптимизированы для разработки приложений с использованием этих API. Эти SDK доступны только на языках Java и Python и используют протокол-последователь JSON RPC. Некоторые популярные функции, такие как библиотека контента, тегирование, vSphere с Kubernetes и т.д., доступны только на этой платформе SDK. Несколько важных замечаний здесь:
  • Функции, такие как управление виртуальными машинами, управление хостами и кластерами, и другие функции, представленные до vSphere 6.5, также частично доступны в vSphere Automation API.
  • Хотя название этого SDK гласит "SDK автоматизации vSphere", оно не ограничивается только vSphere. У них есть клиентские байндинги для VMware Cloud и NSX on VMware Cloud. Это может быть использовано для автоматизации архитектуры Software Defined Datacenter (SDDC).
• Virtual Infrastructure JSON API (VI JSON API) - для разработчиков, которым не нравятся тонкости SOAP, эти API предоставляют интерфейсы REST для всех указанных выше API веб-служб vSphere (VIM). В настоящее время с этими API не связано никаких SDK.

Давайте сосредоточимся только на SDK, основанных на vSphere Web Services (VIM) API и vSphere Automation API. Нам нужно убедиться, что клиентские байндинги функций vSphere доступны с правильными SDK. Руководство по API и документация по языку программирования SDK могут быть хорошей отправной точкой. Для более быстрого понимания вы можете обратиться к таблице ниже, чтобы определить подходящие SDK и руководства по программированию.

Основные функции vSphere в пакетах разработки SDK:

Если вы заинтересованы в создании байндингов к языку программирования на других языках с использованием сторонних инструментов, вы можете использовать WSDL, поставляемые в vSphere Management SDK, или использовать спецификации VI JSON.

При выборе SDK учитывайте ваши навыки в языке программирования, конкретные требования вашего проекта и наличие ресурсов и примеров для выбранного SDK. Кроме того, имейте в виду, что VMware может выпускать обновления и новые SDK, выводить SDK из эксплуатации, поэтому рекомендуется проверять официальную документацию для получения самой последней информации.

На днях компания NAKIVO выпустила бета-версию обновленного продукта для резервного копирования и репликации виртуальных машин NAKIVO Backup & Replication v10.10 Beta. Напомним, что о прошлой версии Backup & Replication v10.9 мы писали вот тут.

Теперь вы можете создавать реплики виртуальных машин на платформе VMware vSphere, включая данные приложений и файлы конфигурации, и поддерживать их актуальность в соответствии с исходной ВМ по мере внесения изменений в почти реальном времени. Достигайте минимальных показателей RTO и RPO в рамках временного окна в 1 секунду.

Вы можете использовать функциональность репликации в реальном времени и аварийное переключение на реплики для:

• Обеспечения доступности критически важных рабочих нагрузок и достижения нулевого простоя во время катастрофы или атаки вымогателей.
• Минимизации периода переключения и избежания простоя, связанного с миграцией данных.

Прежде чем приступить к настройке задания репликации в реальном времени для ВМ, убедитесь, что выполнены следующие предварительные условия для исходного и целевого хостов.

Исходные хосты:

• Установите инструмент I/O Filter на кластер хоста VMware (на исходном хосте). Подробнее об этом тут.
• Чтобы позволить I/O Filter обрабатывать исходные ВМ, которые вы хотите реплицировать, вы должны применить настроенную политику хранения I/O Filter к ВМ или создать политику, если у вас её нет.

Целевые хосты:

• Разверните узел NAKIVO Backup & Replication (Transporter) в качестве виртуального модуля (Appliance) на VMware vSphere на целевом хосте ESXi (для реплицированной ВМ). Подробнее смотрите на этой странице.
• Для запуска заданий репликации в реальном времени на целевом хосте ESXi, вам нужно установить модуль Journal Service на виртуальном модуле под VMware vSphere, развернутом на предыдущем шаге. Подробнее смотрите на странице установка Journal Service.

Скачать бета-версию продукта NAKIVO Backup & Replication v10.10 можно по этой ссылке.

Продолжаем рассказ об анонсах новых продуктов и технологий, сделанных на прошедшей в конце августа конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации.

На прошлой неделе мы рассказали о новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 2, а сегодня поговорим о нововведениях решения для создания отказоустойчивых кластеров VMware vSAN 8 Update 2, а также недавно анонсированном решении VMware vSAN Max.

Продолжая свои начинания по поддержке наиболее критически важных рабочих нагрузок клиентов в плане гибкости, производительности и эффективности, VMware представляет vSAN 8 Update 2 и VMware vSAN Max.

Решение vSAN Max, работающее на архитектуре vSAN Express Storage - это новое предложение в семействе vSAN, которое позволит получить модель развертывания на базе подписки для разрозненных хранилищ, объединяющих петабайты информации на платформе vSphere. Используя vSAN Max, пользователи смогут масштабировать хранилище независимо от вычислительных мощностей для повышения уровня гибкости при поддержке всех своих рабочих нагрузок. Новое предложение vSAN Max будет лицензировано отдельно от существующих версий vSAN. vSAN Max будет предлагаться по подписке и, как планируется, будет лицензирован по метрике на тебибайт (TiB, близко к терабайту).

Кроме нового vSAN Max, улучшения в архитектуре vSAN Express Storage обеспечат новые уровни производительности, а новые функции на платформе vSAN улучшат повседневные операции и пользовательский опыт.

1. Объединенное хранилище масштабов петабайтов

Организации сегодня полагаются на множество приложений для ведения бизнеса, каждое из которых имеет уникальные требования к вычислительной мощности, объему хранения и производительности. Все чаще используются передовые аналитические инструменты, приложения ИИ и приложения, созданные изначально для облачных сервисов, в то время как реляционные базы данных и виртуальные рабочие столы по-прежнему остаются востребованными. Растущее разнообразие рабочих нагрузок и их динамика масштабирования создает потребность в гибкой инфраструктуре, которая позволяет этим критически важным приложениям масштабироваться по мере роста потребностей бизнеса.

С введением vSAN Max клиенты получат больший выбор для развертывания vSAN тем способом, который максимально оптимизирует использование ресурсов и снижает затраты. vSAN Max даст уникальную возможность настраивать кластер vSAN для использования в качестве общего хранилища для кластеров vSphere. Он создан на основе vSAN ESA и дает новые преимущества для клиентов, желающих быстро масштабировать хранилище с высокой производительностью и надежностью. vSAN Max предоставит беспрецедентные уровни масштабируемости и экономической эффективности, повышая отдачу при запуске нагрузок с интенсивным использованием хранилища на гиперконвергентной инфраструктуре (HCI), оптимизируя использование ресурсов и снижая TCO до 30%.

Применяя возможности горизонтального и вертикального масштабирования, пользователи будут иметь полную автономию в том, как увеличивать емкость. Узлы vSAN Max будут предлагать до 7 раз больше плотности, чем узлы HCI, и смогут масштабироваться до более чем 8.5 петабайта в кластере. Клиенты не только смогут масштабировать емкость, но и производительность; каждый добавленный узел в кластер vSAN Max увеличит доступную производительность. И поскольку vSAN Max создан на архитектуре vSAN Express Storage, он может вместить огромные наборы данных и соответствовать строгим требованиям к производительности и надежности, предоставляя до 3,6 миллиона IOPS на кластер хранилищ.

Как и всегда с vSAN, пользователи смогут управлять всеми средами - как традиционной моделью HCI, так и разобщенной моделью Max - из единого интерфейса.

2. Платформа высокой производительности

vSAN 8 U2 вводит несколько улучшений основной платформы, которые обеспечивают совершенно новые уровни производительности, долговечности данных и надежности в архитектуре Express Storage.

• Интегрированные файловые службы (Integrated File Services) для Cloud Native и традиционных рабочих нагрузок

vSAN 8 U2 добавляет файловые сервисы vSAN в архитектуру Express Storage. Клиенты получат преимущества в производительности и эффективности vSAN ESA для своих сред, использующих файловые сервисы vSAN. Все возможности, присутствующие в файловых сервисах vSAN на оригинальной архитектуре хранения (OSA) в предыдущих версиях vSAN, будут расширены для файловых сервисов vSAN на ESA: улучшенная эффективность использования пространства; лучшая производительность; и меньшие домены отказов.

• Улучшенная производительность для разобщенных сред (Disaggregated Environments)

vSAN 8 U1 представил новый адаптивный путь записи на архитектуре Express Storage с целью улучшения производительности для рабочих нагрузок, которые выполняли большое количество записей с высокой частотой, чтобы записать данные альтернативным, оптимизированным способом. Теперь это улучшение имплементировали в разобщенные топологии vSAN 8 U2 с vSAN Max. Теперь ВМ, работающие в кластере vSphere или vSAN и использующие ресурсы хранения другого кластера vSAN ESA или кластера vSAN Max, также смогут использовать эту возможность.

• Внедрение преимуществ vSAN ESA для малых дата-центров и Edge-локаций

vSAN 8 U2 вводит два новых улучшения, которые предоставят гораздо больше гибкости для клиентов, заинтересованных в использовании архитектуры ESA. Во-первых, это введение нового профиля ReadyNode — AF-0 ReadyNode, предназначенного для малых дата-центров и периферийных сред (Edge). Благодаря более низким требованиям к оборудованию, таким как 10Gb NICs, это означает, что клиенты смогут получать преимущества vSAN ESA в средах, которые не требуют производительности, предоставляемой более высокими профилями ReadyNode. Во-вторых, это введение поддержки устройств хранения с меньшим ресурсом записи, "Ready-Intensive". Эти устройства с меньшим ресурсом могут использоваться во многих профилях ReadyNode и предложат более выгодную цену для сред, которые, возможно, не имеют приложений с интенсивными операциями ввода/вывода.

3. Улучшенная управляемость

Производительность, устойчивость и гибкость теряют свой смысл, если решение сложно в эксплуатации. vSAN 8 U2 предлагает несколько новых улучшений, которые упростят повседневные операции администраторов, оптимизируют обнаружение проблем и ускорят время их решения.

• Интеллектуальная стандартная политика упрощает оптимальную конфигурацию

В vSAN 8 U1 появилась новая функция автоматического управления политиками, которая помогает администраторам настраивать свои новые кластеры vSAN ESA с оптимальными уровнями устойчивости и эффективности. В vSAN 8 U2 эта функция стала еще более мощной. При добавлении или удалении хоста из существующего кластера функция автоматического управления политиками будет оценивать, нужно ли корректировать оптимизированную стандартную политику хранения. Если vSAN определяет необходимость изменения, он позволяет изменить затронутую политику хранения одной кнопкой, которая появится в инициированной проверке health-статуса. В этом случае будет переконфигурирована стандартная политика хранения для кластера с новыми оптимизированными настройками политики.

• Отчетность о мощности кластера стала более понятной

В vSAN 8 U2 улучшена отчетность о накладных расходах на емкость для объектов, расположенных в хранилищах данных. Эта новая категория "ESA object overhead" (накладные расходы объекта ESA), размещенная в разделе "Usage breakdown" capacity-дэшборда кластера, сообщает о накладных расходах, связанных с обработкой и хранением данных через лог-структурированную файловую систему vSAN (vSAN LFS). Это улучшение поможет администраторам точнее определить накладные расходы по потреблению емкости в их системе хранения.

• Управление устройствами хранения в большом масштабе

Новая возможность prescriptive disk claim в vSAN ESA позволяет администраторам определять стандартизированный результат требований хостов, входящих в кластер, к диску с точки зрения емкости. vSAN затем попытается применить это желаемое состояние ко всем хостам в кластере. Если он не может применить конфигурацию, будет запущено определение состояния здоровья в Skyline Health для vSAN.

• Улучшенная безопасность через усовершенствованное управление ключами

Поскольку возможности безопасности инфраструктуры продолжают становиться более сложными, vSAN продолжает адаптироваться под поддержку этих новых возможностей. vSAN 8 U2 поддерживает применение серверов KMS, которые используют атрибут "key expiration" для назначения даты истечения ключа шифрования (Key Encryption Key, KEK). Интеграция с Skyline Health для vSAN будет инициировать отчет о состоянии здоровья при приближении сроков истечения ключа, упрощая управление.

• Интуитивное обнаружение ВМ и дисков, потребляющих больше всего ресурсов.

Представление "Top Contributors", появившееся в vSAN 7 U2, предоставляет простой способ определения ВМ, которые создают наибольший спрос на ресурсы, предоставляемые кластером. В vSAN 8 U2 инструмент стал еще лучше, помогая клиентам находить места с наибольшей производительностью не только в любой момент времени, но и в рамках настраиваемых периодов времени.

Администраторы также теперь смогут перемещать элементы в том же виде производительности — будь то IOPS, пропускная способность или задержка, что позволит им быстро оценить ВМ, создающие наибольшую нагрузку на кластер, и определить, не потребляют ли хосты кластера ресурсы непропорционально. Новое представление значительно упрощает устранение проблем с производительностью.

• Улучшенное обнаружение узких мест производительности в растянутых кластерах

vSAN I/O Trip Analyzer — это еще один инструмент, улучшенный в vSAN 8 U2, в нем появилась новая возможность проведения анализа рабочих нагрузок, работающих в растянутом кластере. Пользователь легко сможет определить, где в таком кластере происходит основная задержка, а также задержки в других частях стека, которые могут влиять на общую наблюдаемую ВМ задержку.

• Упрощенная конфигурация для 2-узловых и растянутых кластеров

vSAN 8 U2 упрощает конфигурацию растянутых кластеров и 2-узловых топологий. Администраторы могут помечать трафик vSAN Witness на виртуальном модуле Witness Appliance через настройки конфигурации VMkernel, а также удалять задачу тэгирования трафика Witness через командную строку. Также был увеличен размер Witness Appliance, доступного для vSAN ESA в vSAN 8 U2. В дополнение к размеру "large", клиенты, работающие с этими конфигурациями, также смогут выбрать модуль размера "medium", который потребляет 2 vCPU и 16GB RAM и поддерживает до 500 ВМ.

Решение VMware vSAN 8 Update 2 запланировано к выпуску в третьем квартале этого года. О новых возможностях платформы можно почитать тут, а вот здесь можно узнать про vSAN Max.

Продолжаем рассказ об анонсах новых продуктов и технологий, которые были сделаны на проходящей сейчас конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации.

На этот раз мы расскажем об одном из главных для администраторов виртуальной среды анонсов - релизе платформы VMware vSphere 8 Update 2. Надо сразу сказать, что в третьем квартале будет доступен не только второй пакет обновлений последней версии платформы, но и нововведения облачной подписки vSphere+, о которой мы уже рассказывали.

Итак, давайте посмотрим, что нового в vSphere 8 U2:

1. Повышение операционной эффективности

В этом релизе VMware уделила особое внимание управлению жизненным циклом. Обновления vSphere в больших средах иногда могут быть сложными, так как они часто охватывают всю внутреннюю инфраструктуру, работая иногда на сотнях или тысячах систем. С регулярными улучшениями, патчами и исправлениями безопасности, VMware vSphere должна быстро и легко обновляться. Этот выпуск делает огромный шаг вперед для достижения этой цели. Кроме управления жизненным циклом, VMware облегчила IT-администраторам централизованное управление аутентификацией, продолжая расширять поддержку сторонних поставщиков идентификации.

Давайте посмотрим подробнее:

• Служба управления жизненным циклом ESXi – особенно важным нововведением является новый облачный сервис в vSphere+, который позволяет администраторам централизованно оркестрировать обновления на всем их парке хостов ESXi. Множество операций жизненного цикла (такие как патчи и обновления) должны выполняться учетом сервисов VMware vCenter и границ кластера. Новый облачный сервис, доступный клиентам vSphere+, позволит IT-администраторам обновлять весь парк одинаково настроенных хостов ESXi через несколько серверов vCenter и кластеров одной операцией и централизованно отслеживать ход выполнения из Cloud Console. Рассмотрим пример: с традиционным vSphere, одно обновление требуется для каждого кластера хостов ESXi, и максимальное количество хостов на кластер - 32. Предположим, у пользователя есть 32 000 хостов ESXi, распределенных по 1 000 кластерам. Чтобы обновить весь их парк ESXi, пользователю потребуется выполнить 1 000 отдельных операций обновления. С сервисом управления жизненным циклом ESXi требуется всего одно обновление для каждой стандартной конфигурации оборудования, независимо от количества кластеров. Большинство IT-организаций стандартизируют свои конфигурации оборудования, поэтому в этом случае разумно предположить, что у этого клиента может быть всего около 3-5 стандартных конфигураций оборудования (в зависимости от того, у скольких поставщиков серверов они покупают). Это означает, что они могут обновить весь свой парк ESXi всего за 3-5 операций обновления, что составляет малую долю от 1 000 обновлений, необходимых с традиционным развертыванием vSphere. С сервисом управления жизненным циклом ESXi обновления потребуют гораздо меньше времени и усилий и могут выполняться чаще, позволяя клиентам оставаться более защищенными от ошибок и использовать все последние возможности ESXi.

Кстати, теперь есть возможность попробовать существующие и новые функции vSphere+ перед покупкой:

• Сокращение времени простоя при обновлении vCenter – впервые это было введено для клиентов vSphere+ в прошлом году, но теперь доступность этой функции расширена для всех версий vSphere. Во время обновления время простоя vCenter сокращается примерно с часа до нескольких минут (реальное время может отличаться). По сути, это время, необходимое для завершения работы служб на старом vCenter и запуска служб на новом. Таким образом, необходимые плановые окна обслуживания стали гораздо короче. Обновления можно проводить чаще, так как это гораздо проще сделать, тем самым оперативно переходить на последние версии vCenter.

• Поддержка Microsoft Entra ID (ранее Azure AD) для федерации идентификаторов – за последние пару лет VMware постоянно расширяла поддержку сторонних поставщиков идентификации, включая Microsoft Active Directory Federation Service (ADFS) и недавно была добавлена служба Okta Identity Service. С этим выпуском эта поддержка расширяется далее, включая Microsoft Entra ID (ранее Azure AD). Когда аутентификация обрабатывается сторонним поставщиком идентификации, таким как Entra ID, аутентификация больше не обрабатывается vSphere. Поскольку логины и пароли больше не хранятся внутри vSphere, проверки безопасности проходят проще, быстрее или вообще не требуются.

2. Повышение производительности рабочих нагрузок

С сенсационным появлением ChatGPT в ноябре 2022 года в индустрии возник огромный интерес к генеративному ИИ (GenAI). К январю 2023 года ChatGPT стал самым быстрорастущим потребительским программным приложением в истории, получив более 100 миллионов пользователей. В результате GenAI теперь является стратегическим приоритетом для многих организаций. vSphere была на переднем крае ИИ с момента введения AI-Ready Enterprise Platform в марте 2021 года, и с этим последним выпуском VMware продолжает масштабировать и совершенствовать технологию виртуализации GPU. Наряду с улучшениями, связанными с ИИ, VMware также расширяет доступность технологии Data Processing Unit (DPU) на большем количестве аппаратных платформ, чтобы клиенты могли ощутить эти преимущества производительности.

Тут появились следующие вещи:

• Увеличение максимального количества устройств vGPU на VM с 8 до 16 – большие рабочие нагрузки (особенно ИИ) продолжают требовать все больше и больше мощности GPU. В этом последнем выпуске было увеличено максимальное количество устройств vGPU, которое может быть назначено одной ВМ, до 16, что удвоило верхний предел производительности для больших рабочих нагрузок. Для ИИ это означает, что вы можете сократить время обучения моделей AI/ML и запускать модели самого высокого класса с большими наборами данных.

• Размещение рабочих нагрузок и балансировка нагрузки с учетом GPU в DRS – VMware обнаружила сценарии, в которых рабочие нагрузки могут не полностью использовать доступные ресурсы GPU. Чтобы решить эти проблемы, был улучшен механизм балансировки нагрузки. Теперь DRS учитывает размеры профилей vGPU и объединяет vGPU одного размера на одном хосте. Это также помогает с начальным размещением при включении машин с поддержкой GPU, что позволяет избежать потери емкости GPU из-за фрагментации. Размещение рабочей нагрузки и балансировка нагрузки теперь учитывает GPU, и DRS будет стараться размещать рабочие нагрузки с аналогичными требованиями к профилю на одном хосте. Это повышает использование ресурсов GPU, что снижает затраты, так как для достижения желаемого уровня производительности требуется меньше аппаратных ресурсов графического модуля.

• Расширение поддержки DPU, включая серверное оборудование Lenovo и Fujitsu – год назад, с введением vSphere 8, VMware представила поддержку DPU, позволяя клиентам переносить инфраструктурные рабочие нагрузки с CPU на специализированный модуль DPU, тем самым повышая производительность бизнес-нагрузок. С этим релизом клиенты, использующие серверы Lenovo или Fujitsu, теперь смогут использовать преимущества интеграции vSphere DPU и его преимущества в производительности.

3. Ускорение инноваций для DevOps

Для потребителей инфраструктуры, таких как инженеры DevOps или разработчики, самообслуживание имеет первостепенное значение. Необходимость отправки электронного письма или создания запроса для получения доступа к инфраструктурным услугам, таким как серверы, хранилище или сеть - очень замедляют процессы. С того момента, как VMware представила интеграцию с Kubernetes в 2020 году, продолжается улучшение функций самообслуживания, и этот релиз не исключение. Помимо предоставления пользователям инфраструктуры более быстрого доступа, также была упрощена настройка среды Kubernetes для администраторов ИТ или инженеров DevOps.

Вот что было сделано:

• Новый Image Registry Service для виртуальных машин – для инженеров DevOps или других пользователей, которым нужно создавать виртуальные машины, нужен такой способ хранения образов ВМ, чтобы их можно было повторно использовать или расшаривать их. Этот релиз предоставляет новый Image Registry Service, позволяя потребителям публиковать, изменять и удалять образы с использованием API Kubernetes. Образы могут быть использованы для развертывания машин VM Service. С новым реестром команды DevOps, разработчики и другие потребители VM могут публиковать и управлять образами ВМ в режиме самообслуживания, позволяя создавать их быстрее без необходимости помощи администраторов.

• Поддержка VM Service для Windows и GPU – VM Service - это отличный способ предоставления ВМ в режиме самообслуживания, но в прошлом он был ограничен только машинами Linux и выбранными конфигурациями. Этот релиз убирает эти ограничения. VM Service может быть использован для развертывания машин на Windows наряду с Linux. Также ВМ может быть развернута с любым виртуальным железом, настройками безопасности, устройствами, поддержкой multi-NIC, и устройствами passthrough, которые поддерживаются в vSphere, что позволяет достичь полного соответствия традиционным машинам vSphere. Важно отметить, что теперь VM Service может быть использован для развертывания рабочих ВМ, которые требуют GPU.

• Импорт и экспорт конфигурации Supervisor Cluster – конфигурация супервизор-кластера может занять много времени из-за множества требуемых настроек. Если у вас много кластеров, эта сложность повышается. Теперь конфигурацию Supervisor cluster можно сохранять и экспортировать в другие кластеры. Вы легко можете экспортировать существующую конфигурацию кластера и импортировать в новый супервизор-кластер, минуя ручной процесс конфигурации. Кроме того, это позволит вам более легко воспроизводить стандартную конфигурацию на большом количестве супервизор-кластеров.

4. Прочие улучшения

Здесь нужно отметить следующее:

• Virtual Hardware версии 21 - теперь ВМ получают следующие характеристики:
  • Увеличено максимальное количество vGPU для ВМ до 16.
  • Можно подключать до 256 дисков NVMe к ВМ.
  • Поддерживается спецификация NVMe 1.3 для пользователей Windows и кластерное переключение при отказе Windows Server с дисками NVMe.
  • Проверки на совместимость для новых ОС: Red Hat 10, Oracle 10, Debian 13 и FreeBSD 15.
  • Помните, чтобы полностью использовать эти возможности, вам нужны как vSphere 8 update 2, так и Virtual Hardware 21.
• Расширение поддержки NSX Advanced Load Balancer - NSX-T Load Balancer был объявлен устаревшим, начиная с версии NSX-T 3.2, будьте готовы к скорым изменениям. Начните уже сейчас использовать NSX Advanced Load Balancer или Avi load balancer. Это актуально только для новых установок (Greenfield installations).

• Quality of Service для GPU-нагрузок - с vGPU "время приостановки" (время, когда виртуальная машина временно приостанавливается) во время миграции может быть значительным. Обновление vSphere 8 до версии 2 предоставляет администраторам прекрасный инструмент для оценки максимально возможного времени приостановки ВМ с поддержкой vGPU. Это определяется на основе скорости сети и размера памяти vGPU.

• Понятные сообщения об ошибках - сообщения об ошибках были пересмотрены, чтобы решить долгостоящую проблему пользователей и сделать их более понятными и полезными. Примером этого являются более понятные сообщения об ошибках, отображаемые при блокировке файлов ВМ. В сценариях, когда ВМ не может быть включена, обновленные сообщения будут указывать на заблокированный файл и определять хост с блокировкой.

• Упрощенное развертывание виртуальных машин Windows - в процессе развертывания виртуальных машин Windows были сделаны существенные улучшения. Теперь пользователи могут определить путь OU при создании спецификаций настройки, что приводит к тому, что виртуальные машины Windows развертываются и настраиваются в соответствии с указанным путем OU, оптимизируя их интеграцию в Active Directory.

• Оптимизированные профили конфигурации (vSphere Configuration Profiles) - введенные в vSphere 8 и усовершенствованные в vSphere 8 Update 1, функциональные возможности профилей конфигурации vSphere получили дальнейшее улучшение в Update 2. Всеобъемлющий рабочий процесс в пользовательском интерфейсе облегчает создание, редактирование и применение профилей конфигурации vSphere. Теперь нет необходимости экспортировать документ JSON для редактирования - хотя опция остается. В пользовательский интерфейс была добавлена новая вкладка "Draft", позволяющая пользователям создавать, редактировать и применять черновики или копии существующей конфигурации.

• Улучшенный vSphere Lifecycle Manager (vLCM) - решение vLCM стало настоящим спасением для многих администраторов, и его возможности продолжают улучшаться. На данный момент он поддерживает узлы vSAN Witness и кластеры vSAN, но vSphere 8 Update 2 вносит заметные изменения. Это обновление позволяет vLCM управлять узлами Witness, участвующими в нескольких кластерах vSAN.

• Reliable network recovery - что касается восстановления сети, то для сред, работающих с одним или несколькими распределенными коммутаторами vSphere, процесс восстановления vCenter из резервной копии был упрощен. Когда vCenter восстанавливается из устаревшей резервной копии, он автоматически согласует версии с текущей версией распределенного коммутатора на хостах ESXi.

Доступность для загрузки платформы VMware vSphere 8 Update 2 ожидается в третьем квартале этого года.

Команда VMware приглашает вас присоединиться к бета-программе тестирования платформы vSphere. Это уникальная возможность, чтобы ваша обратная связь была услышана и помогла формировать направления развития vSphere. Участие в бета-программе требует времени и активного участия в таких процессах, как установка последних бета-версий vSphere, выполнение тестов, связанных с некоторыми функциями, а также предоставление отзывов для улучшения конечного продукта.

Некоторые из многих причин участвовать в бета-программе vSphere:

• Ранний доступ для ознакомления с новыми технологиями и улучшениями vSphere.
• Предоставление отзывов напрямую менеджерам продуктов vSphere о функциональности, удобстве использования и производительности.
• Возможность делиться предложениями о будущих функциях, улучшениях, обучении, документации и услугах.
• Обучение и общение с другими техническими специалистами в закрытом онлайн-сообществе.

На эту тему команда VMware недавно записала полезное видео, в котором, помимо прочего, рассказывается о самом комьюнити и о том, какие версии vSphere сейчас проходят бета-тестирование:

Если вы хотели бы участвовать, пожалуйста, нажмите сюда, чтобы подать заявку. Подтвержденные участники будут уведомлены по электронной почте. Обратите внимание, что одобряются заявки только от адресов электронной почты, исходящих от предприятий или организаций, находящихся не в России. Личные адреса электронной почты, такие как Gmail, Hotmail и Yahoo! не будут одобрены.

В начале года мы писали о документе "Performance Best Practices for VMware vSphere 8.0", в котором приведены основные рекомендации по обеспечению высокой производительности флагманской платформы виртуализации компании VMware. В середине этого года было сделано обновление этого руководства, которое было выпущено под названием "Performance Best Practices for VMware vSphere 8.0 Update 1".

Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

• Hardware for Use with VMware vSphere
• ESXi and Virtual Machines
• Guest Operating Systems
• Virtual Infrastructure Management

Все рекомендации, который были даны для vSphere 8, по-прежнему, в силе, мы не нашли новых моментов, касающихся именно Update 1. Но некоторые косметические и уточняющие правки в документе все-таки есть.

Администраторам настоятельно рекомендуется заглядывать в это руководство, хоть оно и состоит из ста страниц. Там просто огромное количество полезной информации, которую можно использовать ежедневно для поддержания высокого уровня производительности виртуальной среды.

Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.

На сайте проекта VMware Labs после долгого перерыва появилась очередная полезная утилита Salt Supervisor Service.

Решение Salt (иногда называемое SaltStack) - это открытая система управления конфигурациями, способная поддерживать удаленные узлы в заданных состояниях. Кроме того, это также распределенная система удаленного исполнения, используемая для выполнения команд и запроса данных на удаленных узлах.

Она была разработана, чтобы объединить лучшие решения в сфере удаленного выполнения и сделать их лучше, быстрее и более гибкими. Salt достигает этого благодаря своей способности обрабатывать большие объемы информации, с помощью не только десятков, но и сотен, даже тысяч отдельных серверов - быстро и через простой и управляемый интерфейс.

VMware Aria Automation Config (ранее известный как vRealize Automation SaltStack Config) - это современная платформа управления конфигурациями с производительностью, скоростью и гибкостью, которые необходимы ИТ-командам для управления большими и сложными ИТ-системами и повышения эффективности в больших масштабах.

VMware vSphere with Tanzu позволяет запускать рабочие нагрузки Kubernetes, используя существующую ИТ-инфраструктуру, преодолевая разрыв между ИТ и разработчиками для cloud-native приложений, размещенных как на локальных серверах, так и в облаке. vSphere Supervisor Services - это сертифицированные Kubernetes-операторы vSphere, которые предоставляют компоненты в качестве услуги инфраструктуры и тесно интегрированные услуги независимых производителей программного обеспечения разработчикам. Вы можете устанавливать и управлять службами Supervisor Services на VMware vSphere with Tanzu, делая их доступными для использования как с традиционными нагрузками, так и с нагрузками в контейнерах Kubernetes.

Salt Supervisor Service позволяет командам DevOps устанавливать и запускать Salt в качестве vSphere Supervisor Service в своем локальном датацентре и автоматически подключать его к SaaS-решению VMware Aria Automation Config.

Скачать утилиту Salt Supervisor Service можно по этой ссылке.

Недавно компания VMware объявила о выпуске обновленной версии облачной платформы Aria Automation Cloud 8.13 (релиз July 2023), предназначенной для автоматизации операций виртуальной инфраструктуры VMware vSphere на платформе VMware Cloud. Напомним, что о возможностях апрельского релиза Aria Automation Cloud 8.12 мы рассказывали вот тут. Главным нововведением апрельского релиза стала архитектура на базе плагинов, ну а сегодня давайте посмотрим на новые возможности этого выпуска.

Теперь в Aria Automation улучшена поддержка Google Cloud Platform (GCP) по сравнению с предыдущим релизом. Чтобы узнать больше технических деталей, прочитайте о поддержке ресурсов GCP в VMware Aria Automation.

Вкратце, вот что мы получили нового:

1. Поддержка учетных записей служб в плагине GCP

Эта функция позволяет пользователям VMware Aria Automation развертывать сервисные учетные записи служб GCP и ключи учетных записей служб с использованием блупринтов (blueprints), каталогов и сервисов Idem.

2. Поддержка балансировщиков нагрузки в плагине GCP

Эта функция позволяет пользователям VMware Aria Automation развертывать балансировщик нагрузки в среде GCP, обеспечивая перенаправление пользователей к ближайшему доступному и наилучшему по производительности экземпляру, уменьшая задержку и улучшая пользовательский опыт.

В дополнение к новым функциям по поддержке публичного облака, также появилось несколько новых возможностей для улучшения механизмов автоматизации.

3. Версии кастомных форм интегрированы с контент-элементами (Content Items)

Пользовательские формы службы VMware Aria Automation Service Broker получили следующее улучшение - пользователи могут настраивать элементы контента, основанные на корневых блупринтах.

• Чтобы создать пользовательскую кастомную форму для конкретных версий блупринта, пользователю нужно нажать на панель деталей, а затем на имя версии (теперь показанное как ссылка), чтобы открыть конструктор форм для этой конкретной версии.
• Добавить кнопку "Disable custom form" в меню действий на панели деталей, которое отключает пользовательскую форму для этой конкретной версии блупринта.
• Добавить одну колонку к таблице версий блупринта с указанием, имеет ли эта версия специфическую для версии пользовательскую форму.
• Переименовать "Delete custom form" в "Delete version-specific custom form" в меню действий таблицы данных на панели деталей.

4. Отмена регистрации созданных машин как действие Day-2 action

Теперь вы можете отменить регистрацию созданных с помощью VMware Aria Automation виртуальных машин vSphere в VMware Aria Automation как действие с ресурсом Day-2 action. Когда вы отменяете регистрацию созданной ВМ, она удаляется из инвентаря VMware Aria Automation, но остается без изменений в vCenter, как это было до выполнения действия. Это улучшение может помочь клиентам освободить лицензии от неиспользуемой ВМ и использовать ресурс лицензий более эффективно.

5. Опциональное игнорирование CPU/памяти выключенных ВМ в политике квоты ресурсов

Пользователи теперь могут выбирать, игнорировать ли CPU и память, потребляемые выключенными ВМ, в политике квоты ресурсов. Это позволяет пользователям, которые ограничены политикой квоты ресурсов, создавать ВМ, даже если они превысили квоты CPU или памяти, если некоторые ВМ, которые учитываются в квоте, выключены. Это улучшение дает пользователям больше гибкости в политике квотирования для использования ресурсов.

6. Ребилд виртуальной машины для Onboarded и Migrated рабочих нагрузок vSphere

В дополнение к появившемуся ранее действию Rebuild (Day 2), VMware теперь поддерживает действие Rebuild для Onboarded рабочих нагрузок vSphere и рабочих нагрузок vSphere, полученных из инструмента помощника миграции (migration assistant). Когда для загруженной ВМ впервые запрашивается Rebuild, пользователь может просмотреть и подтвердить выбор образа, что делается теперь намного проще.

7. Загруженные развертывания соответствуют ограничениям политики Service Broker

Развертывание, включающее ВМ и диски, теперь соответствует ограничениям политики Service Broker. Загруженное развертывание учитывается в описанных ниже лимитах. Вы можете выбрать разрешение на учет ресурсов при загрузке в лимитах, переключив соответствующую опцию в положение "включено". По умолчанию опция выключена, что соответствует поведению, которое было ранее.

Наконец, VMware также добавила два улучшения платформы, чтобы помочь администраторам лучше управлять использованием VMware Aria Automation и настраивать компонент Orchestrator:

8. Видимость оплачиваемых объектов в VMware Aria Automation

С ростом внедрения продуктов VMware через подписку становится критически важным для клиентов понимать, сколько оплачиваемых ресурсов учитывается каждым продуктом.

VMware Aria Automation вводит возможность для администраторов просматривать сводку оплачиваемых объектов под управлением через API и пользовательский интерфейс. Кроме того, ресурсный центр внутри VMware Aria Automation Assembler и VMware Aria Automation Service Broker был улучшен для фильтрации оплачиваемых ресурсов в сочетании с любыми другими фильтрами. Эта возможность помогает администраторам постоянно оценивать свое использование ресурсов и упрощает планирование возобновления подписки или ее расширения.

Вы можете найти следующие обновления на стартовой странице VMware Aria Automation:

9. Поддержка командной строки для настройки VMware Aria Automation Orchestrator

Теперь VMware Aria Automation Orchestrator (бывший продукт VMware Orchestrator) можно настроить через командную строку с использованием команд "vracli vro" в дополнение к использованию Control Center. Это очень удобная для разработчиков функция; пользователи могут использовать командную строку для настройки Orchestrator, а не переходить к другому интерфейсу. Данное улучшение упрощает процесс автоматизированной настройки Orchestrator и предлагает более DevOps-ориентированный подход к конфигурированию решения (подробнее об этом тут).

За более подробной информацией о продукте Aria Automation Cloud обратитесь к Release Notes.

Недавно компания VMware опубликовала интересный документ "VMware vSphere 8 Performance Is in the “Goldilocks Zone” for AI/ML Training and Inference Workloads".

Там приведены результаты тестирования производительности рабочих нагрузок обучения AI/ML на платформе виртуализации VMware vSphere с использованием нескольких графических процессоров NVIDIA A100-80GB с поддержкой технологии NVIDIA NVLink. Результаты попадают в так называемую "зону Голдилокс", что означает область хорошей производительности инфраструктуры, но с преимуществами виртуализации.

Результаты показывают, что время обучения для нескольких тестов MLPerf v3.0 Training1 увеличивается всего от 6% до 8% относительно времени тех же рабочих нагрузок на аналогичной физической системе.

Кроме того, в документе показаны результаты теста MLPerf Inference v3.0 для платформы vSphere с графическими процессорами NVIDIA H100 и A100 Tensor Core. Тесты показывают, что при использовании NVIDIA vGPU в vSphere производительность рабочей нагрузки, измеренная в запросах в секунду (QPS), составляет от 94% до 105% производительности на физической системе.

vSphere 8 и высокопроизводительная виртуализация с графическими процессорами NVIDIA и NVLink.

Партнерство между VMware и NVIDIA позволяет внедрить виртуализированные графические процессоры в vSphere благодаря программному слою NVIDIA AI Enterprise. Это дает возможность не только достигать наименьшего времени обработки для виртуализированных рабочих нагрузок машинного обучения и искусственного интеллекта, но и использовать многие преимущества vSphere, такие как клонирование, vMotion, распределенное планирование ресурсов, а также приостановка и возобновление работы виртуальных машин.

VMware, Dell и NVIDIA достигли производительности, близкой или превышающей аналогичную конфигурацию на физическом оборудовании со следующими настройками:

• Dell PowerEdge XE8545 с 4-мя виртуализированными графическими процессорами NVIDIA SXM A100-80GB
• Dell PowerEdge R750xa с 2-мя виртуализированными графическими процессорами NVIDIA H100-PCIE-80GB

Для вывода в обеих конфигурациях требовалось всего 16 из 128 логических ядер ЦП. Оставшиеся 112 логических ядер ЦП в дата-центре могут быть использованы для других задач. Для достижения наилучшей производительности виртуальных машин во время обучения требовалось 88 логических ядер CPU из 128. Оставшиеся 40 логических ядер в дата-центре могут быть использованы для других активностей.

Производительность обучения AI/ML в vSphere 8 с NVIDIA vGPU

На картинке ниже показано сравнительное время обучения на основе тестов MLPerf v3.0 Training, с использованием vSphere 8.0.1 с NVIDIA vGPU 4x HA100-80c против конфигурации на физическом оборудовании с 4x A100-80GB GPU. Базовое значение для физического оборудования установлено как 1.00, и результат виртуализации представлен в виде относительного процента от базового значения. vSphere с NVIDIA vGPUs показывает производительность близкую к производительности на физическом оборудовании, где накладные расходы на виртуализацию составляют 6-8% при обучении с использованием BERT и RNN-T.

Таблица ниже показывает время обучения в минутах для тестов MLPerf v3.0 Training:

Результаты на физическом оборудовании были получены Dell и опубликованы в разделе закрытых тестов MLPerf v3.0 Training с ID 3.0-2050.2.

Основные моменты из документа:

• VMware vSphere с NVIDIA vGPU и технологией AI работает в "зоне Голдилокс" — это область производительности для хорошей виртуализации рабочих нагрузок AI/ML.
• vSphere с NVIDIA AI Enterprise, используя NVIDIA vGPUs и программное обеспечение NVIDIA AI, показывает от 106% до 108% от главной метрики физического оборудования (100%), измеренной как время обучения для тестов MLPerf v3.0 Training.
• vSphere достигла пиковой производительности, используя всего 88 логических ядер CPU из 128 доступных ядер, оставив тем самым 40 логических ядер для других задач в дата-центре.
• VMware использовала NVIDIA NVLinks и гибкие группы устройств, чтобы использовать ту же аппаратную конфигурацию для обучения ML и вывода ML.
• vSphere с NVIDIA AI Enterprise, используя NVIDIA vGPU и программное обеспечение NVIDIA AI, показывает от 94% до 105% производительности физического оборудования, измеренной как количество обслуживаемых запросов в секунду для тестов MLPerf Inference v3.0.
• vSphere достигла максимальной производительности вывода, используя всего 16 логических ядер CPU из 128 доступных, оставив тем самым 112 логических ядер CPU для других задач в дата-центре.
• vSphere сочетает в себе мощь NVIDIA vGPU и программное обеспечение NVIDIA AI с преимуществами управления дата-центром виртуализации.

Более подробно о тестировании и его результатах вы можете узнать из документа.

Florian Grehl на сайте virten.net опубликовал полезную статью о том, как включить аутентификацию Active Directory / LDAP / LDAPS в инфраструктуре VMware vSphere 8. Приводим ниже ее перевод.

Эта статья описывает, как интегрировать VMware vCenter Server в вашу инфраструктуру аутентификации. Источниками идентификации могут быть развертывания Microsoft Active Directory или протокола OpenLDAP.

В комплекте с управляющим сервером vCenter Server идет внутренняя база данных пользователей, которая позволяет добавлять и управлять пользователями из пользовательского интерфейса. Управление пользователями и единый вход предоставляются встроенным компонентом Platform Service Controller. В большой среде вы, возможно, захотите подключить вашу инфраструктуру виртуализации к централизованно управляемому провайдеру идентификации.

Обратите внимание, что VMware объявила о прекращении поддержки Integrated Windows Authentication (IWA). IWA был методом аутентификации, при котором вы присоединяли vCenter Server к вашему домену Active Directory. Несмотря на то, что Active Directory все еще поддерживается для аутентификации, рекомендуется использовать AD через LDAP или идентификацию с помощью ADFS. Для дополнительной информации см. KB78506.

1. Получение сертификата LDAPS

В связи с рисками безопасности, LDAPS заменяет LDAP как новый протокол каталога. Настоятельно рекомендуется использовать LDAPS, который использует SSL для установления безопасного соединения между клиентом и сервером перед обменом любыми данными. В настоящее время в пользовательском интерфейсе vCenter нет функции получения сертификата, поэтому сертификат нужно загрузить самостоятельно.

Подключитесь к vCenter Server Appliance (или любой системе с установленным OpenSSL CLI) с помощью SSH и войдите как root. Выполните следующую команду, чтобы показать сертификат LDAP:

# openssl s_client -showcerts -connect [LDAPS-Server]:636

Эта команда отображает цепочку сертификатов и информацию о сессии SSL. Вы можете использовать либо сертификат CA, либо сертификат сервера. Использование сертификата CA имеет преимущество в том, что вам не нужно перенастраивать провайдер идентификации, когда сертификат LDAPS заменяется.

Копируем содержимое между строчками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- в текстовый файл.

После этого сохраните полученный файл с расширением .crt.

2. Добавление провайдера идентификации

• Откройте vSphere Client.
• Войдите как Single Sign-On Administrator.
• Перейдите к Administration > Single Sign On > Configuration.
• На вкладке провайдера идентификации откройте Identity Sources.
• Нажмите ADD.

• Измените Identity Source Type на Active Directory over LDAP.

• Заполните остальные поля следующим образом:

Identity source name: Метка для идентификации (нужно указать имя домена)

Base distinguished name for users: Уникальное имя Distinguished Name (DN) начальной точки для поиска на сервере каталогов. Пример: Если ваше имя домена - virten.lab, то DN для всего каталога - "DC=virten,DC=lab".

Base distinguished name for groups: Уникальное имя (DN) начальной точки для поиска на сервере каталогов.

Domain name: Ваше имя домена. Пример: "virten.lab".

Domain alias: Ваше имя NetBIOS. Пример: "virten".

Username: Пользователь домена как минимум с правами просмотра.
Если вы получаете ошибку "Invalid DN syntax.", попробуйте ввести пользователя в формате DN: "uid=administrator,cn=users,dc=virten,dc=lab".

Password: Пароль пользователя домена.

Connect to: Выберите "Connect to any domain controller in the domain", если вы хотите использовать DNS для идентификации контроллеров домена или настроить статические основные и вторичные URL. При использовании статических записей вы можете либо запрашивать локальный каталог (порт 636), либо глобальный каталог (порт 3269). (Для устаревших незащищенных подключений используйте 389/3268). Пример: "ldap://dc.virten.lab:636".

• Нажмите "Browse" рядом с сертификатом (для LDAPS).
• Выберите файл .crt, полученный ранее от сервера LDAP.
• Нажмите "ADD" и завершите мастер настройки.
• В источниках идентификации ваш LDAP должен появиться в списке, и с этого момента вы можете назначать разрешения vCenter пользователям и группам из вашего каталога Active Directory.
• Выберите ваш AD и нажмите кнопку "SET AS DEFAULT", чтобы сделать его доменом по умолчанию для аутентификации в вашем vCenter, что означает, что каждый, кто не указывает имя домена для входа, автоматически аутентифицируется в этом домене.
• Для входа с пользователями AD вам нужно установить разрешения. Чтобы добавить пользователя/группу AD в качестве глобального администратора, перейдите к Administration > Access Control > Global Permissions.
• Нажмите "ADD".
• Выберите домен и начните вводить в поле поиска User/Group, чтобы выбрать Domain entity.

• Нажмите "OK".

Теперь вы должны иметь возможность входить с помощью учетной записи Active Directory. Чтобы решать проблемы, связанные с аутентификацией, проверьте файлы журнала на vCenter Server Appliance в папке /var/log/vmware/sso.

В этом году компания VMware серьезно взялась за доработку своих фреймворков по автоматизации операций в виртуальной инфраструктуре. Это было обусловлено тем, что исторически у VMware накопилось большое количество средств автоматизации, которые когда-то были привязаны к специфическим продуктам и интерфейсам, потом эти продукты эволюционировали, объединялись в различные линейки, а старые интерфейсы продолжали тянуться за разными решениями, управлять которыми до сих пор можно несколькими разными способами, а с учетом различных платформ и вспомогательных сервисов таких способов становится слишком много.

На сайте проекта virten.net появилось отличное руководство о том, как правильно настроить USB-накопитель (обычную флэшку), подключенный к хосту VMware ESXi 8.0 в качестве датастора, откуда можно запускать виртуальные машины. Для производственной среды этого делать, само собой, не рекомендуется, а вот для тестирования различных возможностей хоста vSphere данная инструкция может оказаться очень полезной.

Итак:

Рекомендации по выбору USB-накопителя

Касательно форм-фактора или типа USB-накопителей нет никаких ограничений. Вы можете использовать маленькие флешки USB, большие жесткие диски USB 3.5" с высокой емкостью или внешние твердотельные накопители на базе USB. Из-за проблем с производительностью и надежностью, не рекомендуется использовать дешевые USB-флешки для хранилищ.

Предварительные условия

Некоторые команды требуют доступа по SSH к хосту ESXi, который можно включить из vSphere Client:

vSphere Client > ESXi Host > Configure > System > Services > SSH > Start

Это же можно сделать из VMware ESXi Host Client:

ESXi Host Client > Host > Manage >  Services > TSM-SSH > Start

После этого вы можете зайти на хост ESXi по SSH с помощью любого клиента, например, PuTTY.

Шаг 1 - отключаем USB Passthrough

Дефолтное поведение хоста ESXi при присоединении USB-накопителя к хосту - дать возможность его проброса в виртуальную машину через механизм USB Passthrough. Поэтому нам нужно отключить этот механизм.

Есть 3 способа это сделать:

• На базе устройства с помощью команды esxcli passthrough
• На базе модели с использованием расширенных настроек USB quirks
• Полностью отключить его для всех устройств, отключив сервис usbarbitrator

1 - Отключаем USB Passthrough на базе устройства

Этот способ основан на параметрах USB Bus и Vendor ID. Эта настройка сохраняется при перезагрузке, но учтите, что она может перестать работать в условиях, когда изменяются идентификаторы Bus ID или Device ID (например, вы воткнете флэшку в другой порт, либо будет присоединено другое устройство на время отсутствия флэшки в порту).

Итак, втыкаем USB-накопитель в хост ESXi и соединяемся с ним по SSH как root. Выводим список USB-устройств командой:

esxcli hardware usb passthrough device list

Для следующей команды вам потребуется записать параметры четырех выделенных колонок в формате Bus#:Dev#:vendorId:productId (например, 1:4:1058:1140).

Отключаем проброс для устройства:

После этого перезагружать хост ESXi не требуется.

2 - Отключаем USB Passthrough, используя USB Quirks

Второй вариант отключает USB Passthrough для конкретной модели (сочетание идентификатора производителя и идентификатора продукта) с использованием расширенных настроек USB Quirks.

Вставьте USB-накопитель в ваш ESXi, подключитесь к хосту ESXi с использованием SSH и войдите под root. Далее просмотрите доступные USB-устройства. Первое число - это идентификатор производителя, второе число - идентификатор продукта:

lusb

Для установки USB Quirks нужно указать ID в следующем формате (см. скриншот выше): 0xDeviceID:0xVendorID  (например, 0x1058:0x1140).

Отключите USB passthrough, используя следующую команду:

esxcli system settings advanced set -o /USB/quirks -s 0x1058:0x1140:0:0xffff:UQ_MSC_NO_UNCLAIM

Здесь уже нужно перезагрузить хост ESXi для применения изменений.

3 - Отключаем USB Arbitrator

Перед началом процедуры не втыкаем флэшку в сервер.

Заходим в клиент vSphere Client, идем в ESX > Configure > System > Advanced System Settings и нажимаем Edit... Далее найдем параметр USB.arbitratorAutoStartDisabled и установим его в значение 1:

После этого перезагружаем хост ESXi и уже после этого втыкаем флэшку в сервер.

То же самое можно сделать с помощью CLI-команды через SSH (после нее можно уже втыкать флэшку):

Также можно отключить USB Arbitrator следующей командой, которая будет применена после перезагрузки хоста:

Шаг 2 - создаем VMFS Datastore на флэшке

После того, как вы отключили проброс USB, можно создавать датастор через vSphere Client, кликнув правой кнопкой на хосте ESXi и выбрав Actions > Storage > New Datastore... (в ESXi Host Client это делается в разделе Storage > New Datastore).

Если ваше устройство не отображается в мастере New Datastore, нужно сделать ресканирование хранилищ (опция Rescan Storage по правому клику) и убедиться, что устройство присутствует в списке.

Если и это не помогло, то можно попробовать создать датастор с помощью командной строки. Находим путь к устройству (Device Path в формате mpx.vmhba##). Для этого запускаем команду:

esxcli storage core device list |grep '^mpx' -A3

В выводе команды вы сможете идентифицировать устройство по его размеру:

Если у вас несколько устройств одного размера, то после подключения нужного вам устройства загляните в лог /var/log/vmkernel.log и посмотрите там наличие вот такой записи:

vmkernel: Successfully registered device "mpx.vmhba34:C0:T0:L0" from plugin "NMP" of type 0

Это и есть ваша флэшка. Теперь создаем переменную с этим устройством:

После этого создаем метку для данного устройства:

Теперь с помощью утилиты partedUtil создадим раздел с идентификатором GUID=AA31E02A400F11DB9590000C2911D1B8:

partedUtil "setptbl" "${DISK}" "gpt" "1 2048 $(eval expr $(partedUtil getptbl ${DISK} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1) AA31E02A400F11DB9590000C2911D1B8 0"

И отформатируем раздел в формат VMFS:

После этого ваш том, созданный на флэшке, появится в списке датасторов хоста.

Для бесплатного резервного копирования виртуальных машин можно использовать скрипт ghettoVCB.

Если вы заметите, что скорость копирования на/с датастора с помощью команд cp, mv или scp очень медленная, то вы можете использовать механизм Storage vMotion или утилиту vmkfstool для копирования данных.

Например, вот так можно склонировать VMDK-диск:

Известные проблемы

Когда вы пытаетесь определить диск, дважды проверьте, что вы не перепутали свои накопители. Имя, отображаемое в пользовательском интерфейсе, не меняется, когда меняется идентификатор. Вот пример, где выделенный диск был перенесен на виртуальный адаптер mpx.vmhba33 как новое устройство. Отображаемое имя при этом остается старым - mpx.vmhba32.

Существующие датасторы не монтируются автоматически! То есть, если на вашей флэшке уже есть тома VMFS, то они не будут видны при ее подключении. В этом случае датастор будет offline, а в логе vmkernel.log вы увидите вот такое сообщение:

cpu0:65593)LVM: 11136: Device mpx.vmhba34:C0:T0:L0:1 detected to be a snapshot:

То есть датастор определяется как снапшот. Список снапшотов вы можете вывести командой:

# esxcli storage vmfs snapshot list
583b1a72-ade01532-55f6-f44d30649051
Volume Name: usbflash
VMFS UUID: 583b1a72-ade01532-55f6-f44d30649051
Can mount: true
Reason for un-mountability:
Can resignature: true
Reason for non-resignaturability:
Unresolved Extent Count: 1

В этом случае вы можете смонтировать датастор следующей командой, используя VMFS UUID:

Недавно мы писали о том, что нового появилось в средствах автоматизации VMware vSphere: API, JSON, OpenAPI, а также о новом протоколе VI/JSON от VMware для управления инфраструктурой vSphere. Сегодня мы поговорим о последних нововведениях инфраструктуры фреймворка PowerCLI, сделанного на базе движка PowerShell.

Использование командлетов PowerShell/PowerCLI для автоматизации предлагает множество преимуществ, таких как простота установки на множестве различных операционных систем и мощный язык сценариев, поддерживающий команды, специфичные для VMware.

PowerCLI отлично интегрируется с экосистемой VMware, обеспечивая совместимость и бесшовную интеграцию с продуктами vSphere, vSAN, NSX, VMC, SRM и другими. Несмотря на то что PowerCLI работает автономно со своим собственным циклом выпуска, VMware стремимся синхронизировать его с официальными релизами vSphere. Это гарантирует, что клиенты PowerCLI не будут долго ждать доступа к новым функциям и возможностям, поставляемым в новых версиях VMware vSphere.

Вызовы VMware PowerCLI

Как и в других сферах автоматизации, сейчас есть некоторые проблемы, с которыми сталкиваются как в самой VMware, так и клиенты при использовании PowerCLI. В первую очередь здесь стоит возможность использовать PowerCLI на всех платформах, на которых работает PowerShell. Большинство людей ассоциируют PowerShell с Microsoft Windows, что вполне логично, но PowerShell Core становится довольно популярным на платформах Linux и MacOS. VMware стремится поддерживать эти платформы на том же уровне, что и для Windows.

Во-вторых, по мере эволюции VMware vSphere и других продуктов VMware, PowerCLI также должен меняться, и делать это быстро, чтобы успевать за нововведениями продуктовой линейки. Этот быстрый темп не должен влиять на удобство использования и качество командлетов PowerCLI. Поэтому стоит задача расширения охвата PowerCLI для продуктов за более короткий период времени, при этом нужно обеспечить требуемое качество модулей и командлетов.

Поддержка нескольких платформ

Когда PowerCLI 13.0 был выпущен в ноябре 2022 года, это был первый PowerCLI, полностью совместимый с PowerShell Core, который работает на Microsoft Windows, Linux и Apple MacOS. Это означает, что образец кода или сценарий можно запустить на любой из этих платформ, запланировать с помощью cron на Linux и т.п. Это делает его очень гибким в качестве инструмента автоматизации, и это означает больше возможностей для инструментов оркестрирования операций.

Автоматизация средств автоматизации

В выпуске PowerCLI 12.4 VMware представила инновационный подход к генерации командлетов: через механизмы автоматизации. Была автоматизирована генерация командлетов для vSphere Automation API, которая была выпущена в рамках нового модуля под названием VMware.SDK.vSphere. Этот подход позволяет быстро создавать командлеты и модули для поддержки новых функций, обеспечивая при этом качество и последовательность.

Однако успех этой стратегии во многом зависит от качества API самих продуктов. Ближайшая цель VMware - обеспечить выпуск API с высокими стандартами качества, которые также соответствуют требованиям PowerCLI.

Обширность покрытия

В последующих релизах после 12.4 продолжали внедрять новые модули PowerCLI на основе подхода автоматического генерирования, такие как модули VMware.Sdk.Nsx.Policy, VMware.Sdk.SRM и VMware.Sdk.VR.

Например, введенный в PowerCLI 12.6 модуль VMware.Sdk.Nsx.Policy позволяет клиентам управлять NSX Policy API и является важной частью мультиоблачных операций, помогая устанавливать контроль над безопасностью, независимо от того, где работает ваша нагрузка.

В выпуске 12.7 были добавлены новые командлеты для указания пороговых значений проверки "здоровья" vSAN в рамках модуля VMware.CimAutomation.Storage.

Выпуск 13.0 сделал PowerCLI мультиплатформенным инструментом, что также означало, что модули, такие как VMware.ImageBuilder и VMware.DeployAutomation, должны быть совместимы с Apple MacOS и Linux. Кроме того, были добавлены новые команды для управления дисками кластера vSAN ESA и обновлен модуль VMware.VimAutomation.Cloud для поддержки функций API VMware Cloud Director 10.4.

В последнем на данный момент выпуске PowerCLI 13.1, было представлено два новых модуля: VMware.Sdk.VR для поддержки REST API VMware vSphere Replication и VMware.Sdk.Srm для поддержки REST API VMware Site Recovery Manager. Также там добавили новые командлеты для офлайн-депозиториев Lifecycle Manager, удаленного управления хранилищем данных vCenter Server, прямого управления дисками vSAN, выключения кластера, монтирования удаленных хранилищ данных vSAN из расширенных кластеров vSAN и многого другого.

Что дальше?

Следующие шаги - это поддержание высокого уровня удобства использования и качества модулей и командлетов PowerCLI. VMware продолжает улучшать собственные инструменты, которые генерируют автоматизированные команды, а также проверяют и верифицируют исходные API в самих продуктах на предмет качества. Эти усилия приносят пользу всем средствам автоматизации, а не только PowerCLI.

Также будет расширяться охват PowerCLI за счет введения новых модулей и улучшений в существующих. Хорошим примером является поддержка автоматизации VMware Cloud Foundation, позволяющая клиентам контролировать, настраивать и автоматизировать эти среды так же легко, как они делают это с vSphere.

Наконец, будем продолжать поддерживаться кроссплатформенность, что позволит пользователям Windows, Linux и MacOS на равных использовать PowerCLI.

На сайте проекта VMware Labs вышло очередное обновление утилиты vSphere Diagnostic Tool 1.1.6. Напомним, что это python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О последнем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.

Давайте посмотрим на новые возможности vSphere Diagnostic Tool 1.1.5:

Общие улучшения:

• Увеличен таймаут проверок с 10 до 20 секунд
• Исправлена проблема, когда версия/топология идентифицировались некорректно

Проверка VC VMDIR:

• Была добавлена проверки Domain Functional Level (DFL) для обнаружения дополнительных возможных проблем

Проверка сертификатов vCenter:

• Проверка идентификатора ключа на предмет того, что он не заполнен
• Новая проверка для подсчета объектов CRL в разделе TRUSTED_ROOT_CRLS

Скачать VMware vSphere Diagnostic Tool 1.1.6 можно скачать по этой ссылке.

В некоторых случаях, когда клиенты используют физические тома pRDM в своей среде, время загрузки хоста VMware ESXi или повторное сканирование хранилища может занимать больше времени, чем обычно. Причина этих долгих процессов заключается в том, что каждый LUN, подключенный к хосту, сканируется при загрузке или во время повторного сканирования хранилища. Обычно тома RDM используются для класторов Microsoft WSFC или других кластерных приложений и не используются хостом напрямую. Во время сканирования ESXi пытается прочитать разделы на всех дисках, но не может это сделать для устройств, постоянно зарезервированных WSFC. В связи с этим, загрузка хоста или повторное сканирование устройств хранения может занимать большое время. WSFC использует механизм SCSI-3 Persistent Reservation для контроля блокировки между узлами WSFC, что блокирует возможность чтения их хостами ESXi.

VMware рекомендует внедрять постоянное резервирование (perennial reservation) для всех хостов ESXi, на которых размещаются узлы ВМ, использующие RDM. Для получения более подробной информации посмотрите статью KB1016106.

Итак, возникает вопрос: как можно заставить хост не сканировать эти RDM, тем самым сокращая время загрузки или повторного сканирования?

Существует флаг устройства под названием "Perennially Reserved", который сообщает хосту, что RDM не должен сканироваться, и что устройство используется в другом месте на постоянной основе. До vSphere 7 этот флаг можно было включить только через CLI и для этого требовался UUID (naa.ID).

Команда для установки флага в значение true:

esxcli storage core device setconfig -d <naa.id> --perennially-reserved=true

Установку флага можно проверить командой:

esxcli storage core device list -d <naa.id>

В выводе команды в случае установленного флага будет следующая строка:

Is Perennially Reserved: true

При установке этой опции ее нужно запустить для каждого соответствующего тома RDM, используемого кластером WSFC, и на каждом хосте ESXi с доступом к этому RDM. Вы также можете установить флаг "Perennially Reserved" в профилях хостов.

С выпуском vSphere 7, возможность установки флага "Perennially Reserved" в значение "true" была добавлена в пользовательский интерфейс в разделе устройств хранения. Также было добавлено поле для отображения текущего значения флага "Perennially Reserved".

После выбора RDM для постоянного резервирования, у вас есть возможность отметить устройство как зарезервированное ("Mark as perennially reserved") для текущего хоста или нескольких хостов в кластере. Это устраняет ручной процесс установки опции для каждого хоста через CLI. Также вы все еще можете использовать для этих целей ESXCLI, PowerCLI или профили хостов.

Когда вы нажмете Yes статус резервирования для устройств обновится в интерфейсе:

Теперь для зарезерированных устройств будет доступна опция снятия этого флага ("Unmark as perennially reserved"):

Важное примечание: вы должны использовать флаг "Perennially Reserved" только для RDM или LUN, которые вы не хотите сканировать. LUN стандартных хранилищ ESXi НЕ должны быть помечены этим флагом.

Ну и весь этот процесс можно также увидеть в видео от VMware:

Не так давно мы писали о протоколе VI/JSON от VMware для управления инфраструктурой vSphere. В то же время, у VMware в последнее время появилось много чего еще нового в сфере средств для автоматизации управления виртуальной инфраструктурой, о будущем которых мы сегодня и поговорим, обратив внимание на такие интерфейсы, как API, JSON, OpenAPI.

1. VMware vSphere API

VMware vSphere за последние годы стала значительно более сложным продуктом и теперь предлагает несколько разных типов API-технологий. Наиболее значимыми сегодня являются:

• vSphere Web Services API, который использует протокол SOAP
• vSphere Automation API, который использует принципы проектирования REST

Наличие нескольких API добавляет сложности в управление и эксплуатацию сложных сред. Эта сложность проявляется в разных аспектах, начиная с необходимости в нескольких инструментах, знаниях и навыках, в зависимости от API. Кроме того, разные API "висят" на разных эндпоинтах и требуют разные механизмы аутентификации по историческим причинам и для обеспечения обратной совместимости.

Обе категории API документированы отдельно, каждая со своими справочными руководствами и примерами кода. Это может вызвать путаницу для администраторов, поскольку они часто предполагают, что должны выбирать между REST API или SOAP API, но на самом деле им нужно использовать оба. REST не является заменой для SOAP API, но дополняет его.

В плане API компания VMware работает в трех основных направлениях:

• Упрощение использования API
• Упрощение документации
• Улучшение опыта разработчиков и унификация протоколов и наборов инструментов

Основные ресурсы, с которых надо начать знакомство с этими API, это:

• vSphere Automation REST API Programming Guide
• vSphere Web Services Programming Guide
• Understanding the vSphere Automation API
• Code Samples

2. Протокол JSON для Web Services API

Во-первых, начиная с vSphere 8 Update 1, был введен новый протокол JSON для всех Web Services API в VMware vSphere. Это помогает унифицировать опыт разработки, позволяя разработчикам использовать общие инструменты, и преобразует SOAP API для применения более REST-подобного подхода. Этот JSON API в vSphere 8 Update 1 и новее предоставляет полный набор функциональных возможностей, предлагаемых традиционным vim25 SOAP API.

Во-вторых, были сохранены та же структура, управляемые объекты и имена методов, чтобы клиенты могли перенести существующие решения для автоматизации на новый протокол JSON с минимальными изменениями.

Наконец, VMware предлагает спецификации OpenAPI 3.0 в дополнение к документации по JSON API виртуальной инфраструктуры. VMware также ведет работу по объединению документацию по JSON API с документацией по Automation API, где задокументированы все REST-сервисы. Это приближает момент создания единого места для поиска документации клиентами.

3. Формат OpenAPI 3.0

В будущем VMware перенесет оставшиеся публичные интерфейсы SOAP-сервисов (SPBM, SMS, EAM, VLSM) на эти же форматы, предоставляя спецификации OpenAPI 3.0 для каждого из них и интеграцию с документацией REST API.

После этого следующим улучшением будет предоставление единого механизма аутентификации для REST API и нового протокола JSON для SOAP API. Это упростит создание решений для автоматизации и обеспечит общую сессию для всех сервисов vSphere.

Окончательным шагом на этом пути улучшения будет предоставление всех сервисов через единый эндпоинт, с которым администраторы смогут вызывать все API vSphere. Это значительно упростит использование API в vSphere и обеспечит более качественное документирование, тем самым улучшая опыт разработки.

Компания VMware выпустила очень интересный документ, рассказывающий о производительности рабочих нагрузок в публичном облаке Oracle Cloud, построенном на базе инфраструктурного стека VMware vSphere - "Leveraging the Full Power of Oracle Cloud VMware Solution and VMware vSphere".

Он раскрывает аспекты производительности виртуальных машин, работающих в инфраструктуре решений вендоров VMware, Oracle, AMD и Deloitte:

В этом документе рассматривается, как именно Oracle Cloud VMware Solution (OCVS) отличается от публичных облачных сред IaaS. Там также приводится описание следующих процессов:

• Перенос виртуальных машин Oracle и SQL Server из локального датацентра в облако OCVS без перенастройки с обеспечением того же уровня производительности.
• Демонстрация, как облако OCVS, работающее на оборудовании с процессорами AMD EPYC, достигает повышения производительности баз данных.
• Наглядно показывается, что NSX Data Center может ускорить работу с нагрузками Oracle со ссылками на исследования VMware и Deloitte Consulting.
• Обоснование экономических и технических преимуществ управления хостами со стороны клиентов.

Об облаке OCVS

OCVS включает следующие продукты VMware: vSphere, vSAN, NSX Data Center и vCenter Server. Эта унифицированная облачная инфраструктура и платформа для операций позволяет ИТ-специалистам предприятий быстро переносить и модернизировать приложения, бесшовно перемещая рабочие нагрузки между локальными средами и инфраструктурой Oracle Cloud Infrastructure (OCI) в больших масштабах. Кроме того, ИТ-команды могут легко использовать такие сервисы, как Oracle Autonomous Database, Oracle Exadata Cloud и Oracle Database Cloud, имея постоянный доступ к облачному порталу и современные API.

Производительность OCVS

VMware vSphere - это проверенная корпоративная платформа виртуализации, которая успешно работает с виртуальными машинами Oracle более 12 лет. Как показано на рисунке ниже, виртуальная машина Oracle Database, выполняющая сложную корпоративную нагрузку в OCVS, работает почти так же хорошо, как и в локальном датацентре. Когда мы масштабируем виртуальные машины Oracle Database до 8, виртуальные машины на OCVS работают даже немного лучше, чем виртуальные машины в локальных средах.

Также, используя эталонный тест VMware для измерения производительности базы данных DVD Store, компания Deloitte в независимом исследовании показывает, что виртуальные машины Oracle Database работают до 4-8 раз быстрее с VMware NSX, как показано на рисунке:

За более подробной информацией об исследовании производительности облака OCVS обращайтесь к документу "Leveraging the Full Power of Oracle Cloud VMware Solution and VMware vSphere".

В 2021 году мы писали об использовании дисков VMDK на платформе VMware vSphere в режиме Multi-writer для кластерных решений. Этот режим предназначен для поддержки технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) и для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance, когда требуется использование общего диска в кластерной конфигурации.

В этом случае необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли производить запись в файл VMDK одновременно с нескольких хостов ESXi (можно также организовать и запись от нескольких ВМ на одном хосте). Этот режим со стороны VMware поддерживается только для некоторых кластерных решений, таких как Oracle RAC, и для технологии Fault Tolerance, у которой техника vLockstep требует одновременного доступа к диску с обоих хостов ESXi.

В статье, на которую мы сослались выше, хоть и неявно, но было указано, что режим "Multi-writer" используется и для кластеров Microsoft Windows Server Failover Clustering (WSFC, ранее они назывались Microsoft Cluster Service, MSCS), однако это была неверная информация - он никогда не поддерживался для кластеров Microsoft.

Мало того, использовать режим "Multi-writer" для WSFC не только не рекомендуется, но и опасно - это может привести к потере данных. Кроме того, возможности поддержки VMware в этом случае будут очень ограничены.

Информация о поддержке "Multi-writer" и общих дисков VMDK

Использование файлов VMDK в качестве общих дисков для виртуальных машин Windows в среде vSphere возможно, но только когда файлы VMDK хранятся в кластеризованном хранилище данных с включенной поддержкой Clustered VMDK, как описано в статье Clustered VMDK support for WSFC, или ниже в этой статье.

Сначала предупреждения и предостережения - прежде чем предпринимать любые из описанных в этой статье шагов, администратору очень важно понять и принять, что VMware не гарантирует, что эти конфигурации не приведут к потере данных или их повреждению.

Итак, какие варианты предлагает VMware, если вы уже используете кластеры WSFC в режиме multi-writer:

• Переконфигурирование общих дисков на основе файлов VMDK для кластеризованных виртуальных машин Windows, которые были настроены с использованием опции флага multi-writer.
• Перемещение файлов VMDK в одно или несколько официально поддерживаемых хранилищ данных с поддержкой Clustered VMDK.
• Представление файлов VMDK обратно виртуальным машинам таким образом, чтобы минимизировать или избежать необходимости перенастройки внутри гостевой операционной системы или на уровне приложений.

VMware настоятельно рекомендует клиентам, выполняющим эти задачи, убедиться в наличии проверенного и повторяемого плана отката в случае сбоя во время выполнения этих операций. Предполагается и ожидается, что у клиентов имеются проверенные резервные копии всех данных и информации о конфигурации всех виртуальных машин, которые будут участвовать в этом процессе переконфигурации.

Как минимум, клиенты должны выполнить (или отметить) следующее перед началом этих процедур:

• Текущие конфигурации виртуальных машин, особенно:
  • Диски – какие файлы VMDK соответствуют каким томам в гостевой операционной системе.
  • Имена и расположение файлов для КАЖДОГО диска VMDK.
  • Номер SCSI и SCSI ID, к которому подключен КАЖДЫЙ диск. Мы должны присоединить диск к ТОМУ ЖЕ SCSI ID при повторном подключении.
  • В Windows - текущий владелец ресурсов диска (проверить это можно в конфигурации WSFC).
• Если владение ресурсами WSFC разделено между узлами, ПЕРЕКЛЮЧИТЕ ВСЕ РЕСУРСЫ на один узел. Это упрощает процесс реконфигурации и очень полезно, чтобы избежать путаницы. Выключите все пассивные узлы ПЕРЕД выключением активного узла. После завершения настройки необходимо включить сначала активный узел, а затем остальные узлы.

Переконфигурация кластера WSFC с Multi-Writer на режим Clustered VMDK

Давайте начнем с рассмотрения нашей текущей конфигурации, посмотрим на узлы (кликабельно):

И на диски:

Протестируем WSFC путем переключения ресурсов диска - в данном случае мы выключаем активный узел и наблюдаем, как кластерные ресурсы становятся доступными на пассивном узле. Этот тест очень важен для проверки работоспособности WSFC перед внесением изменений.

Текущая конфигурация общих дисков (отображение распространенной неправильной конфигурации с включенным multi-writer, где общие диски принадлежат выключенной третьей виртуальной машине).

Вот узел WSFC Node-1 и его расшаренные диски (флаг Multi-Writer установлен в Enabled):

Читайте статью далее->

Компания VMware на днях объявила о выпуске обновленной версии решения VMware Aria Operations Cloud релиз July 2023, предназначенного для комплексного управления и мониторинга виртуальной среды на платформе VMware vSphere в облаке. Напомним, что о новых возможностях январской версии продукта мы писали вот тут.

Давайте посмотрим на новые возможности платформы:

1. Поддержка Microsoft Azure Government

Эта функция была разработана в основном для агентств правительства США и их партнеров, она предлагает услуги IaaS, PaaS и SaaS. Данная функция обеспечивает физическую изоляцию дата-центров и сетей, расположенных только в США, и соответствует стандартам безопасности и соблюдения требований правительства. Обратите внимание: поддержка Azure Government Secret в настоящее время недоступна.

Поддержка подписок на Azure Government доступна в 5 регионах:

• US Gov Arizona
• US Gov Texas
• US Gov Central
• US Gov Virginia
• US Gov East

Подписки управляются через встроенную интеграцию с Microsoft Azure. Пользователи могут выбирать между коммерческими или государственными подписками с соответствующими услугами и регионами. Если вы используете коммерческие подписки, можно использовать дэшборды, алерты и контент, доступные для коммерческих подписок, а потом использовать их для государственных подписок без каких-либо дополнительных настроек.

Настройка регионов Azure Government Regions:

2. Интерфейс командной строки Cloud Proxy CLI

Интерфейс командной строки Cloud Proxy был усовершенствован - теперь он позволяет выполнять проверку соединения. Ее можно использовать для конфигураций с заранее определенными эндпоинтами, такими как Gateway, S3 и узлы кластера, в зависимости от того, находится ли кластер на локальном сервере или доступен как SaaS. Он также включает возможности проверки маршрута трассировки и просмотра информации об окружении. У VMware Aria Operations также есть фоновое задание, которое проверяет связь с этими конечными точками.

Опции использования Cloud Proxy CLI (подробнее об этом тут):

3. Уведомление о работе системы (Notification Heartbeat)

Функция Notification Heartbeat позволяет вам использовать правила Notification Rules для повторной отправки активных алертов на желаемые эндпоинты, пока они остаются активными. По умолчанию этот флажок не выбран. Как только эта опция установлена, система постоянно проверяет статус алертов, которые соответствуют правилу уведомления.

4. Поиск по метрикам в панели Troubleshooting Workbench

Тут появились следующие улучшения:

• Теперь появилась улучшенная возможность поиска объектов с использованием запросов. Используйте метрики, свойства или суперметрики, связанные с типами объектов. Вы можете добавлять условия, используя несколько метрик и условий.

• Опции autocomplete для помощи в составлении запросов и быстрого изучения синтаксиса.
• Автоматическая проверка синтаксиса запроса поможет вам правильно его построить.
• Новая страница для результатов поиска:
  • Подробное изучение метрики
  • Выполнение сверток
  • Запуск панели устранения неполадок
• Фильтрация результатов, чтобы помочь вам сузить область поиска.
• Поиск автоматически сохраняется на время сессии в виде плитки на панели troubleshooting workbench.

Более подробно об этом можно почитать вот тут.

5. Апгрейды для Compliance Pack

Пакет соответствия CIS обновлен для поддержки следующих бенчмарков:

• CIS_VMware_ESXi_6.7_Benchmark_V1.3.0
• CIS_VMware_ESXi_7.0_Benchmark_V1.2.0

Также теперь есть определения алертов, специфичные для версий.

NSX-T Compliance pack был обновлен для поддержки следующих стандартов:

• NSX-T 3.2 Security Configuration Guide
• NSX-T 3.1 Security Configuration Guide
• NSX-T 3.0 Security Configuration Guide

Также появились обновленные определения алертов в сценариях автоматической проверки комплаенса.

6. Улучшения Launchpad

Действие Learn More на некоторых карточках открывает объясняющее видео:

7. Новая метрика доступности для объектов мониторинга приложений

Для объектов мониторинга приложений добавлена новая метрика "Telegraf availability’", чтобы понять, получаются ли данные от агента Telegraf. Она применима как для curated, так и для open source агентов Telegraf (подробнее тут).

8. Скрипты PowerShell собирают данные для обнаружения служб без учетных данных

Теперь обнаружение служб использует скрипты PowerShell для сбора данных с виртуальных машин Windows в сценариях без учетных данных.

9. Защита платформы

VMware Aria Operations теперь имеет встроенные защитные механизмы для отслеживания изменений в метриках или свойствах Management Pack. Там, где наблюдаются частые изменения значения строки метрики или значения свойства, они отображаются в виде предупреждения о защите платформы. В текущем релизе это должен включить администратор, но в будущих релизах это может быть включено по умолчанию.

Более подробно о VMware Aria Operations Cloud можно почитать на странице продукта.

В июне компания VMware сделала анонс большого обновления своей архитектуры VMware Cloud Foundation версии 5.0. Этот крупный релиз платформы предлагает дополнительную масштабируемость, безопасность и несколько ключевых улучшений, которые направлены на соответствие требованиям для инфраструктур IaaS, упрощают развертывание облачных услуг на собственных площадках и обеспечивают дополнительную защиту от кибератак.

Недавно мы писали о большом релизе облачной архитектуры VMware Cloud Foundation 5.0 (VCF), неотъемлемой частью которой является решение VMware NSX, предназначенное для для виртуализации, агрегации и централизованного управления сетями виртуального датацентра.

Напомним, что VCF - это главное программное комплексное инфраструктурное решение VMware, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

Недавно мы писали о нововведениях Aria Suite (vRealize Suite) в составе VCF 5.0, а сегодня посмотрим, какие новые возможности предоставляет решение NSX 4.1, которое поставляется в составе этой архитектуры.

Давайте взглянем на основную новую функциональность NSX:

Если кратко, то вот основные моменты, которые заслуживают внимания:

• VMware Cloud Foundation 5.0 с поддержкой NSX 4.1 предлагает усовершенствования платформы, такие как многопользовательский доступ к ресурсам сети и NAPP 4.0.1.1.
• Antrea - это проект, совместимый с платформой Kubernetes, который реализует CNI и политики сетей Kubernetes для обеспечения сетевой связности и безопасности рабочих нагрузок в подах (pods). NSX 4.1 представляет новые усовершенствования сетевого взаимодействия и безопасности контейнеров, которые позволяют создавать правила сетевого экрана с комбинацией виртуальных машин и ingress/egress объектов Kubernetes.
• Дополнительные службы сетевой маршрутизации уровня 3 становятся доступными для фабрики VMware Cloud Foundation Fabric за счет развертывания маршрутизации между VRF.
• Улучшенная онлайн-система диагностики, которая содержит шаги для отладки и устранения конкретных проблем.

Теперь рассмотрим все это подробнее:

Улучшения в области сетевого взаимодействия и безопасности

VMware Container Networking with Antrea предлагает пользователям подписанные образы и бинарные файлы, а также полную корпоративную поддержку для проекта Antrea. VMware Container Networking интегрируется с управляемыми сервисами Kubernetes для дальнейшего улучшения сетевых политик Kubernetes. Также поддерживаются рабочие нагрузки Windows и Linux на Kubernetes в нескольких облаках.

NSX 4.1 имеет новые улучшения в области сетевого взаимодействия и безопасности контейнеров, которые позволяют создавать правила сетевого экрана с комбинацией виртуальных машин и объектов Kubernetes. Кроме того, можно создавать динамические группы на основе тегов NSX и меток Kubernetes. Это улучшает удобство использования и функциональность управления кластерами Antrea с помощью NSX.

Пользователи имеют возможность создания политик сетевого экрана, которые разрешают и/или блокируют трафик между различными виртуальными машинами и модулями Kubernetes в одном правиле. Также вводится новая точка принудительного выполнения, которая включает все эндпоинты, а эффективное применение (apply-to) определяется на основе исходных и целевых групп участников.

Более эффективная защита от кибератак с функциональностью NDR

По мере того как сетевые атаки становятся все более распространенными, возрастает важность использования новейших функций в области безопасности. Развертывание NSX 4.1.0 как части VMware Cloud Foundation 5.0 с новыми возможностями распределенного сетевого экрана в сочетании с новыми функциями NDR улучшает защиту.

Технология обнаружения и реагирования на сетевые угрозы (Network Detection and Response, NDR) позволяет команде безопасности визуализировать цепочки атак, преобразуя огромное количество сетевых данных в несколько "кампаний вторжения". NDR строит такие визуализации, объединяя и сопоставляя события безопасности, такие как обнаруженные вторжения, подозрительные объекты и аномальные сетевые потоки.

Усовершенствованная система онлайн-диагностики

Онлайн-диагностика предлагает предопределенные руководства (runbooks), которые содержат шаги отладки для устранения конкретной проблемы. Руководства по устранению неполадок или runbooks - это серия шагов или процедур, которые следует выполнять для диагностики и устранения проблем в системе или приложении. Они разработаны для структурированного подхода к устранению неполадок и помогают быстро и эффективно решать проблемы.

Эти руководства можно вызвать через API, и они запустят шаги отладки с использованием CLI, API и скриптов. После отладки будут предложены рекомендуемые действия для исправления проблемы, а сгенерированные в ходе отладки артефакты можно загрузить для дальнейшего анализа.

Больше технических ресурсов и руководств для архитектуры VMware Cloud Foundation 5.0 вы можете найти на этой странице.

Нашелся очень интересный ресурс - вебсайт Operationalize Your World (OYW), где рассказано о современных методах управления виртуальной инфраструктурой VMware vSphere. Помимо этого, там есть очень много всего полезного, в том числе и для загрузки.

Все материалы по данной теме собраны в одном месте и состоят из следующих компонентов:

• Презентация PowerPoint - она используется для обсуждений внутри компании и для возможности аудитории адаптировать и представить фреймворк внутри компании CIO и командам, отвечающим за приложения.
• Набор инструментов Aria (vRealize) Operations - он состоит из дэшбордов, обзоров, суперметрик и алертов, которые вы можете импортировать в свою инфраструктуру. Он создан на основе актуальной версии vRealize Operations. Эти инструменты не тестировались на более ранних версиях, поэтому сначала обновите вашу инфраструктуру до последней версии.
• Книга - представляет собой редактируемый документ в формате Microsoft Word. Это документация OYW, которую клиенты могут принять и адаптировать в качестве своего внутреннего руководства по эксплуатации.
• Сайт VMwareOpsGuide - он охватывает больше, чем книга, но содержание сайта немного отстает, поскольку требуется время и усилия для ручной синхронизации сотен страниц, которые обновляются автором каждый месяц.

Собственно книга носит полное название "vSphere Metrics - Deep dive into VMware vCenter and ESXi performance and capacity counters" и представляет собой документ на 211 страницах.

Материалы книги абсолютно бесплатны и полностью Open Source. То есть, вы можете взять любые фрагменты из этой книги, изменить как нужно под нужды вашей организации (например, для руководств по эксплуатации) и использовать их без ограничения.

В общем, очень и очень полезный ресурс!

Одной из сильных сторон VMware vSphere является обширное количество API, которые позволяют управлять платформой. Более тысячи API, варьирующиеся от основных операций с виртуальными машинами до виртуализации хранилищ и сетей, от кластеризации до управления ресурсами, позволяют организациям любого размера настраивать vSphere под свои конкретные потребности и автоматизировать различные рабочие процессы для экономии времени и средств.

С момента их появления более 15 лет назад, API управления виртуальной инфраструктурой (VI) обрели широкое применение. Множество продуктов и бесчисленное количество скриптов разработаны с учетом этих API, и многие разработчики знакомы с их моделью разработки. В то же время, VI API основаны на протоколе SOAP, который в свою очередь разработан на основе XML. Несмотря на свою мощь, за годы XML доказал свою сложность как формат данных, имеющий свою долю проблем с безопасностью. Учитывая эти проблемы, разработчики и системные дизайнеры прибегают к JSON в качестве замены XML в области API.

Чтобы удовлетворить спрос и облегчить интеграцию в окружения, работающие только с JSON, начиная от веб-браузеров и до современных языков программирования, таких как Go, VMware представила новый протокол, основанный на JSON и похожий на REST, под названием VI/JSON.

Новый протокол является современной альтернативой устаревшему SOAP и предоставляет те же VI API на тех же эндпоинтах, с той же моделью безопасности. Одной из главных целей нового протокола VI/JSON является максимальное облегчение перехода от SOAP для новых пользователей VI API. Кроме того, для приложений, основанных на SDK, миграция на VI/JSON может быть выполнена полностью на платформе с минимальными изменениями в приложении.

В дополнение к полной обратной совместимости API, новый протокол предоставляет прямой доступ к так "managed properties" - почти 300 типов записей, представляющих состояние различных виртуализованных элементов, управляемых vSphere, начиная от виртуальных машин до сетей, хостов, кластеров и т.д. Ранее управляемые свойства были доступны только косвенно через многофункциональный инструмент Property Collector. Сегодня простой HTTP GET-запрос может получить доступ ко всем управляемым свойствам.

Для VI/JSON, похожесть на REST означает, что управляемые ресурсы и операции кодируются в URL-адресе запроса, а не в теле сообщения, как требуется в SOAP. Это изменение предоставляет множество преимуществ: упрощает интеграцию в сетевых экранах на уровне API, облегчает анализ трафика и упрощает написание скриптов. Аналогично, кодировка данных на основе JSON облегчит разработку для многих пользователей VI API.

И наконец, улучшены также и аспекты безопасности. Вместо использования HTTP-кук для идентификации сессии, новый протокол использует специальный HTTP-заголовок, предотвращающий классическую атаку, известную как межсайтовая подделка запроса (Cross-Site Request Forgery), когда третья сторона может украсть идентификационные данные пользователя.

Чтобы дать представление о новом протоколе, вот такой запрос может быть использован для включения виртуальной машины (заголовки протокола HTTP опущены для краткости):

POST /sdk/vim25/8.0.1.0/VirtualMachine/vm-42/PowerOnVM_Task

Эквивалентный запрос SOAP выглядит следующим образом. Обратите также внимание на обязательное тело, которое не требуется для простых запросов VI/JSON.

POST /sdk

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope ...>
    <soapenv:Body>
       <PowerOnVM_Task xmlns="urn:vim25">
          <_this versionId="8.0.1.0" type="VirtualMachine">vm-42</_this>
       </PowerOnVM_Task>
    </soapenv:Body>
</soapenv:Envelope>

Новый протокол уже включен в состав последнего релиза VMware vSphere 8 Update 1. Более подробную информацию по работе с ним вы можете получить здесь.

Вчера мы рассказывали о новых возможностях архитектуры корпоративного уровня VMware Cloud Foundation 5.0. Напомним, что VCF - это главное программное комплексное инфраструктурное решение VMware, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

Сегодня мы расскажем о новых возможностях пакета vRealize Suite (новое название линейки - Aria), которые дают дополнительную масштабируемость, безопасность и несколько ключевых улучшений, которые направлены на соответствие требованиям для инфраструктур IaaS, упрощают развертывание облачных услуг на собственных площадках и обеспечивают дополнительную защиту от кибератак.

Итак, давайте посмотрим на ключевые новые возможности vRealize Suite:

• Новое в Aria (vRealize) Operations (vROps)

vROps предоставляет предиктивное и превентивное управление ИТ-операциями для частных, гибридных и многооблачных сред на единой платформе. Процесс внедрения VMware Cloud Foundation был упрощен для предоставления пользователям более глубокого понимания и контекста управления продуктами VMware Cloud Foundation. Механизм работы с логами был улучшен для обеспечения большей глубины данных и контекста за счет таких функций, как анализ трендов логов, поддержка фильтров для продвинутого решения проблем, виджет логов в панелях инструментов и поддержка полей логирования для сообщений логов.

Чтобы помочь клиентам получить целостное представление обо всех объектах, которые отслеживаются в vROps, была добавлен дэшборд многооблачной среды, отображающий все облака VMware и публичные облака, которые пользователи могут мониторить, а также показывает сводную информацию о том, что происходит в важнейших объектах, связанных с этим облаком.

Кроме того, такие функции, как улучшения планирования сценариев "Что если", и анализ стоимости облачной среды VMware, могут помочь клиентам анализировать и сравнивать стоимость всех их объектов и прорабатывать сценарии планирования для оптимизации затрат.

• Новое Aira (vRealize) Operations for Log Insights (vRLI)

Масштаб данных, генерируемых для инфраструктуры различных приложений огромен, и vRealize Operations for Log Insights (vRLI) предоставляет возможность понять эти данные. В новом релизе vRLI предлагает полное 360-градусное устранение неполадок, объединяющее метрики, журналы и многочисленные интеграции. Страница Webhooks улучшена для обеспечения последовательного рабочего процесса, такого как определения алертов и отчеты.

Возможности управления журналами для SaaS позволяют настраивать оповещения, которые помогают управлять расходами на SaaS с лучшей видимостью. Многие другие обновления для SaaS включают федеративное управление журналами, пакеты контента и новые API. Обновленные отчеты об использовании помогают понять объем данных, которые приложения отправляют в журналы, чтобы помочь управлять затратами на их хранение.

• Новое в Aria (Realize) Operations for Network Insights (vRNI)

vRNI предоставляет клиентам простой, легкий в использовании инструмент для управления сетью, который позволяет мониторить поток данных по всей инфраструктуре безопасным образом. Автоматическое обнаружение сети - это одна из новых мощных функций vRNI, с помощью которой можно автоматически обнаруживать устройства, такие как коммутаторы, маршрутизаторы и межсетевые экраны, во всей сети с помощью проверенных механизмов.

Благодаря этой функции сетевой администратор может легко определить, сколько устройств находится в сети, как ускорить добавление устройств и определить незавершенные сетевые пути. Улучшения удобства использования руководства по устранению неполадок в сети включают новые виджеты, обновленные диаграммы метрик, а также действия с деревом зависимостей, такие как фильтры и расширения. Новые сетевые метрики для интерфейсов ESXi Host pNIC, а также ядер CPU NSX-T Edge dataplane дополнительно улучшают процесс устранения неполадок.

• Новое в Aria (vRealize) Automation (vRA)

vRA позволяет ИТ-командам устранять неэффективность процессов с помощью end-to-end автоматизации. Теперь vRA поддерживает настраиваемые действия и действия "из коробки", выполняющиеся на одном и том же ресурсе или развертывании, что повышает эффективность и сокращает временные затраты. Новая архитектура плагинов раскрывает полный спектр возможностей, предлагаемых облачными провайдерами внутри vRA.

• Новое в Aria (vRealize) Suite Lifecycle Manager (vRSLCM)

vRSLCM теперь предоставляет интеграцию между продуктами vRealize Suite. С помощью vRLI вы теперь можете выполнять настройку переадресации журналов из других продуктов vRealize Suite в vRLI. Аналогично, с помощью vROps Manager, вы теперь можете выполнять настройку пакетов управления других продуктов vRealize в vRealize Operations Manager. Пользователи могут включать или отключать проверки состояния для продуктов vRealize Suite в vRSLCM. Если обновление vRA не удалось, вводится функция автоматического возврата, чтобы вернуть приложение к его предыдущему рабочему состоянию. Перед автовозвратом из vRealize Automation автоматически собирается support bundle и сохраняется в vRSLCM для целей устранения неполадок. Вы можете перейти к нужному продукту vRA в vRSLCM и загрузить последний сгенерированный support bundle.

Еще несколько полезных ресурсов о новой версии VMware Cloud Foundation 5.0:

• Announcing VMware Cloud Foundation 5.0
• What’s New with vSphere and vSAN in VCF 5.0
• What’s New with NSX in VMware Cloud Foundation 5.0
• VMware Cloud Foundation 5.0 Release Notes